Player FM - Internet Radio Done Right
57 subscribers
Checked 1d ago
Ajouté il y a cinq ans
Inhoud geleverd door Tim Klein, Dominique Winter, Oliver Winter, Tim Klein, Dominique Winter, and Oliver Winter. Alle podcastinhoud, inclusief afleveringen, afbeeldingen en podcastbeschrijvingen, wordt rechtstreeks geüpload en geleverd door Tim Klein, Dominique Winter, Oliver Winter, Tim Klein, Dominique Winter, and Oliver Winter of hun podcastplatformpartner. Als u denkt dat iemand uw auteursrechtelijk beschermde werk zonder uw toestemming gebruikt, kunt u het hier beschreven proces https://nl.player.fm/legal volgen.
Player FM - Podcast-app
Ga offline met de app Player FM !
Ga offline met de app Player FM !
Podcasts die het beluisteren waard zijn
GESPONSORDE
In a difficult week for Los Angeles, we hope this episode can provide a little bit of respite. Jessica Shaw is joined by Keely Flaherty from Tudum for a deeper dive into the gripping limited series, American Primeval , starring Betty Gilpin and Taylor Kitsch. Then also talk about the delightful return of Cameron Diaz and Jamie Foxx in the new action comedy, Back in Action , directed by Seth Gordon. Follow Netflix Podcasts for more and read about all of the titles featured on today’s episode exclusively on Tudum.com .…
Die Produktwerker
Markeer allemaal (on)gespeeld ...
Manage series 2586512
Inhoud geleverd door Tim Klein, Dominique Winter, Oliver Winter, Tim Klein, Dominique Winter, and Oliver Winter. Alle podcastinhoud, inclusief afleveringen, afbeeldingen en podcastbeschrijvingen, wordt rechtstreeks geüpload en geleverd door Tim Klein, Dominique Winter, Oliver Winter, Tim Klein, Dominique Winter, and Oliver Winter of hun podcastplatformpartner. Als u denkt dat iemand uw auteursrechtelijk beschermde werk zonder uw toestemming gebruikt, kunt u het hier beschreven proces https://nl.player.fm/legal volgen.
Im Podcast der Produktwerker besprechen wir Themen rund um die Rolle des Product Owners. Dazu tauschen wir uns nicht nur untereinander aus, sondern sprechen auch mit interessanten Gesprächspartnern aus allen möglichen Themenbereichen von Product Ownern. Die Produktwerker sind Tim Klein (@produktwerkCGN), Oliver Winter (@oliwin) und Dominique Winter (@designik). Als Experten für Produktentwicklungen haben wir uns in der agilen Community Kölns kennen und schätzen gelernt. Wir drei wollen die Kompetenz von Product Ownern und Produktorganisationen fördern, bessere Produkte und Services zu entwickeln. Wir freuen uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker.
…
continue reading
258 afleveringen
Markeer allemaal (on)gespeeld ...
Manage series 2586512
Inhoud geleverd door Tim Klein, Dominique Winter, Oliver Winter, Tim Klein, Dominique Winter, and Oliver Winter. Alle podcastinhoud, inclusief afleveringen, afbeeldingen en podcastbeschrijvingen, wordt rechtstreeks geüpload en geleverd door Tim Klein, Dominique Winter, Oliver Winter, Tim Klein, Dominique Winter, and Oliver Winter of hun podcastplatformpartner. Als u denkt dat iemand uw auteursrechtelijk beschermde werk zonder uw toestemming gebruikt, kunt u het hier beschreven proces https://nl.player.fm/legal volgen.
Im Podcast der Produktwerker besprechen wir Themen rund um die Rolle des Product Owners. Dazu tauschen wir uns nicht nur untereinander aus, sondern sprechen auch mit interessanten Gesprächspartnern aus allen möglichen Themenbereichen von Product Ownern. Die Produktwerker sind Tim Klein (@produktwerkCGN), Oliver Winter (@oliwin) und Dominique Winter (@designik). Als Experten für Produktentwicklungen haben wir uns in der agilen Community Kölns kennen und schätzen gelernt. Wir drei wollen die Kompetenz von Product Ownern und Produktorganisationen fördern, bessere Produkte und Services zu entwickeln. Wir freuen uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker.
…
continue reading
258 afleveringen
Tous les épisodes
×D
Die Produktwerker
Tim & Dominique im Gespräch Cost of Delay, auf Deutsch Verzögerungskosten, beschreibt die wirtschaftlichen Verluste, die entstehen, wenn ein Produkt oder Feature später als geplant auf den Markt kommt. In der neuen Folge von der Produktwerker diskutieren Tim und Dominique, warum dieses Konzept für Product Owner zentral ist und wie es uns bei strategischen Entscheidungen helfen kann. Dominique definiert Cost of Delay als die Summe aller wirtschaftlichen Kosten, die durch Verzögerungen entstehen. Das reicht von entgangenen Umsätzen und Marktanteilen bis hin zu Lizenz- oder Wartungskosten für alte Systeme. Ein Beispiel zeigt, wie ein verspäteter Systemwechsel zu Millionen Euro zusätzlichen Lizenzgebühren führen kann. Aber auch weiche Faktoren wie verlorene Marktreputation oder Kundenzufriedenheit können in die Bewertung einfließen. Besonders praktisch wird Cost of Delay bei der Priorisierung von Backlog-Items. Features können wie verderbliche Waren betrachtet werden: Je später sie geliefert werden, desto geringer ihr Nutzen. Um das zu quantifizieren, benötigt man eine klare Formel. Ein gängiger Ansatz ist, die Kosten pro Zeiteinheit zu berechnen, zum Beispiel pro Woche oder Sprint, und diese durch die Größe der Arbeit zu teilen. Dieser Ansatz ähnelt dem Konzept Weighted Shortest Job First (WSJF). In der Praxis ist jedoch nicht immer alles messbar. Dominique und Tim betonen, dass Schätzungen oft auf Annahmen basieren müssen. Dabei geht es nicht um absolute Genauigkeit, sondern um eine Diskussion, die ein gemeinsames Verständnis schafft. „Es ist besser, mit unscharfen Daten zu arbeiten, als gar keine Grundlage zu haben“, so Dominique. Wichtig sei es, Annahmen zu dokumentieren und regelmäßig zu überprüfen. Darübe rhinaus ist ein weiterer spannender Aspekt die enge Verbindung zwischen Cost of Delay und der Produktstrategie. Unternehmen müssen abwägen, ob sie lieber schnell liefern oder auf Perfektion setzen wollen. Diese Entscheidung hat nicht nur Einfluss auf die Priorisierung einzelner Aufgaben, sondern auch auf die langfristige Marktpositionierung. Die Folge schließt mit wertvollen Tipps für den Einstieg in das Thema Cost of Delay. Tim und Dominique raten dazu, sich zunächst auf einfache Annahmen zu stützen und diese regelmäßig zu überprüfen. Denn nur wer die Kosten von Verzögerungen versteht, kann nachhaltig erfolgreiche Produkte entwickeln. Passend zur aktuellen Folge empfehlen wir euch übrigens noch diese Folge, weil sie thematisch sehr passen und in der Folge referenziert werden: Technische Schulden und wie wir als Product Owner damit umgehen ( https://produktwerker.de/technische-schulden/ ) Flow Metriken für Scrum Product Owner ( https://produktwerker.de/flow-metriken/ ) Product Principles ( https://produktwerker.de/product-principles/ ) Produktstrategie in die Praxis bringen ( https://produktwerker.de/produktstrategie-in-die-praxis-bringen/ )…
Tim & Oliver im Gespräch In dieser Folge der Produktwerker geht es darum, wie Product Roadmaps in der täglichen Arbeit eingesetzt werden können. Zu Beginn eines Jahres investieren viele Product Owner und Produktmanager viel Energie in die Erstellung einer Product Roadmap. Doch was passiert danach? Die Roadmap, die oft als Ergebnis intensiver Diskussionen und strategischer Planung entsteht, ist kein statisches Dokument, sondern ein dynamisches Werkzeug, das den Alltag von Produktteams prägen sollte. Eine Product Roadmap gibt die Richtung vor. Sie bildet die Brücke zwischen der Produktvision und den operativen Aufgaben im Backlog. Damit wird sie zur Operationalisierung der Produktstrategie und hilft dabei, Entscheidungen fundierter zu treffen. Gerade in Gesprächen mit Stakeholdern bietet sie eine klare Orientierung, welche Outcomes und Ziele im Fokus stehen. Anstatt über einzelne Features zu diskutieren, lenkt die Roadmap die Aufmerksamkeit auf die übergeordneten Ziele und erlaubt es, neue Anforderungen kritisch zu hinterfragen. Im Scrum-Kontext erweist sich die Product Roadmap als besonders nützlich. Ob im Sprint Planning, bei der Formulierung eines Sprintziels oder im Sprint Review – die Roadmap sorgt für eine klare Verbindung zwischen Vision, Strategie und operativer Umsetzung. Sie zeigt auf, wie das aktuelle Sprintziel auf die langfristigen Produktziele einzahlt. Darüber hinaus unterstützt sie Product Owner, den Fokus zu behalten, etwa in Diskussionen über Prioritäten oder neue Feature-Wünsche. Auch im Kontext von Product Discovery bietet die Roadmap Orientierung. Unsicherheiten, die bei der Entwicklung auftreten, können systematisch angegangen werden. Sie ermöglicht es, Hypothesen oder Annahmen gezielt zu priorisieren und ihre Relevanz für das Gesamtbild zu bewerten. Dabei wird der iterative Charakter der Roadmap deutlich: Neue Erkenntnisse führen zu Anpassungen, um sicherzustellen, dass das Produkt den Anforderungen des Marktes gerecht wird. Product Roadmaps in der täglichen Arbeit einzusetzen erfordert Engagement und Disziplin. Sie ist mehr als nur ein Dokument – sie ist ein zentraler Bestandteil der Produktarbeit und unterstützt dabei, langfristige Ziele mit den täglichen Aufgaben zu verbinden. Indem sie regelmäßig reflektiert und angepasst wird, trägt sie dazu bei, die Produktentwicklung effektiv und zielgerichtet zu gestalten.…
Götz Müller im Gespräch mit Tim In der dieser Folge der Produktwerker spricht Tim mit Götz Müller, einem erfahrenen Experten für Lean Management in der Produktentwicklung und Gastgeber des langjährigen Podcasts „Kaizen 2 go“. Gemeinsam beleuchten sie die Verbindung zwischen Lean Thinking und moderner agiler Produktentwicklung. Dabei steht eine zentrale Frage im Fokus: Was können Product Owner und Produktmanager von den Prinzipien des Lean Product Development lernen? Götz Müller bringt eine beeindruckende Expertise mit. Seit den 1990er Jahren beschäftigt er sich intensiv mit Lean Thinking, das ursprünglich im Kontext von Toyota und der Automobilindustrie entstand. Der Grundgedanke dabei ist ebenso einfach wie kraftvoll: Verschwendung vermeiden und den Wertstrom optimieren – vom ersten Kundenwunsch bis hin zur tatsächlichen Lieferung des Produkts. Lean Thinking ist auch in der digitalen Produktentwicklung relevant. Obwohl Lean oft mit der Massenproduktion assoziiert wird, lassen sich viele Prinzipien übertragen. Lean Management fordert beispielsweise, den Entwicklungsprozess kontinuierlich zu verbessern und stets die Perspektive des Kunden einzunehmen – sei es ein externer Kunde oder ein interner Abnehmer, wie etwa die Produktion in der Hardwareentwicklung. Ein spannender Aspekt ist die Rolle des sogenannten Chief Engineers im Lean-Kontext. Dieser definiert das Produkt in seiner Gesamtheit und trägt die Verantwortung dafür, dass alle Beteiligten auf ein gemeinsames Ziel hinarbeiten. Diese Rolle zeigt Parallelen zur Product-Owner-Rolle in Scrum, geht jedoch weit darüber hinaus, indem sie strategische, technische und menschliche Dimensionen miteinander verbindet. Die Diskussion dreht sich zudem um die Herausforderungen, die entstehen, wenn Hardware- und Softwareentwicklung eng verzahnt sind. Hier betont Götz, dass unterschiedliche Entwicklungszyklen und „Sprachen“ der beiden Bereiche oft zu Missverständnissen führen können. Ein tiefes Verständnis der jeweiligen Bedürfnisse und klare Kommunikation sind essenziell, um diese Hürden zu überwinden. Ein zentrales Learning aus Lean Thinking für Product Owner ist die Bedeutung von kontinuierlicher Verbesserung. In kleinen, iterativen Schritten sollte nicht nur das Produkt, sondern auch der gesamte Entwicklungsprozess optimiert werden. Dabei geht es nicht nur darum, effizient zu arbeiten, sondern vor allem effektiv – mit einem klaren Fokus auf den tatsächlichen Mehrwert für den Kunden. Das Gespräch zeigt eindrucksvoll, wie wichtig die Haltung der kontinuierlichen Verbesserung, auch bekannt als Kaizen, für erfolgreiches Produktmanagement ist. Lean Management in der Produktentwicklung bietet eine wertvolle Perspektive, um in einem unsicheren und komplexen Umfeld bessere Entscheidungen zu treffen. Die Verbindung von Lean und agilem Denken ermöglicht es, nicht nur schneller zu liefern, sondern auch langfristig nachhaltige Werte zu schaffen. Eine wertvolle ältere Folge unserer Podcasts in diesem Zusammenhang gibt es auch: Kennt Kanban Product Owner? (mit Michael Mahlberg) Wer tiefer in das Thema einsteigen möchte, findet weitere wertvolle Inhalte im Podcast „Kaizen2go“ von Götz Müller. Viel weiteres Material gibt es auf seiner Webseite https://www.geemco.de/ Für Product Owner und Produktmanager, die ihre Arbeit um Lean-Prinzipien bereichern wollen, ist dies eine hervorragende Quelle der Inspiration. Und wer weitere Fragen an Götz Müller hat oder bzgl. Unterstützungsbedarf mit ihm reden möchte, kommt auch über sein LinkedIn-Profil sehr gut mit ihm in Kontakt. Wir hoffen, dass du einige neue Impulse aus den Erfahrungen von Götz gewinnen konntest. Hast du selber schon explizite Erfahrungen mit Lean Management gemacht und magst darüber berichten? Wir Produktwerker freuen uns, wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
In dieser Folge erzählt Dominique, warum er in diesem Jahr auf Themen statt klassischer Ziele setzt. Üblicherweise nimmt er sich jedes Jahr konkrete Ziele vor, doch oft bleibt das Gefühl, nicht wirklich zufriedenstellend voranzukommen. Daher hat er für 2025 einen neuen Ansatz gewählt: Ein Meta-Thema, das als Leitfaden für das gesamte Jahr dient. Nach einer ausführlichen Abwägung entschied er sich für das Thema Gesundheit. Um es greifbarer zu machen, unterteilte er es in drei Dimensionen: Körperliche Gesundheit: Bewegung, Schlaf und Vorsorge. Mentale Gesundheit: Stressreduktion, Achtsamkeit und kreative Hobbys. Soziale Gesundheit: Beziehungen pflegen, neue Kontakte knüpfen. Für jede Dimension sammelte er 50 Ideen, um aktiv daran zu arbeiten – von Spaziergängen bis hin zu Freiwilligenarbeit. Diese Listen bieten Inspiration und Flexibilität, um je nach Bedarf neue Wege auszuprobieren. Wöchentlich überprüft Dominique mithilfe von Selbstauskunft, Tracking-Tools und Reflexion, wie es ihm in den drei Bereichen geht. So kann er seinen Fokus flexibel anpassen und gezielt dort ansetzen, wo er sich verbessern möchte. Sein Ansatz: Flexibilität statt Frust, Ganzheitlichkeit und Motivation durch Vielfalt. Ob das ganze funktioniert? Das kann Dominique jetzt noch nicht sagen, aber einen Versuch ist es wert.…
Was bedeutet die aktuelle Diskussion für Product Owner? Die Aussage "Agile is dead" macht aktuell die Runde und sorgt für lebhafte Diskussionen auch in der Product-Owner-Community. Ist das Ende agiler Methoden wirklich erreicht, oder handelt es sich um eine missverstandene These? In dieser Folge der Produktwerker spricht Kai Simons mit Oliver über diese Frage und mögliche Auswirkungen auf Product Owner. Kai Simons, Gründer von Agile Growth und Certified Scrum-Trainer der Scrum Alliance, beleuchtet, warum der Ruf nach dem "Tod von Agilität" in der Luft liegt. Dabei sieht er die Wurzeln dieser Aussage weniger in einem Versagen der agilen Prinzipien, sondern vielmehr in der Art und Weise, wie diese umgesetzt wurden. "Agile Methoden sind leicht zu verstehen, aber schwer zu meistern", betont Kai. Viele Organisationen scheitern nicht an den Ideen, sondern an der konsequenten Transformation und den Rahmenbedingungen, die dafür notwendig sind. Für Product Owner bringt diese Diskussion einige Herausforderungen und Chancen mit sich. Die Rolle erfordert nicht nur fachliche Expertise, sondern auch Leadership-Qualitäten und die Fähigkeit, eine klare Produktvision zu entwickeln und zu kommunizieren. Kai teilt aus seiner Erfahrung, wie oft die falschen Personen diese Verantwortlichkeiten übernehmen, ohne den nötigen Mut, Entscheidungen zu treffen oder die strategische Weitsicht mitzubringen. Dieses Missverständnis trägt zu dem Frust bei, der Agilität als gescheitert erscheinen lässt. Ein zentraler Punkt der Diskussion ist das Vertrauen – sowohl in die eigenen Fähigkeiten als Product Owner als auch in das Team und die Organisation. Nur wenn Product Owner und Teams das Vertrauen aufbauen und halten können, lassen sich agile Prinzipien effektiv umsetzen. Die Verbindung zwischen den agilen Werten und der Realität im Unternehmen ist entscheidend. In vielen Fällen fehlen jedoch die Unterstützung durch Scrum Master oder ein Verständnis dafür, wie die Zusammenarbeit mit Entwicklern gestaltet werden muss, um langfristig erfolgreich zu sein. "Agile is dead" muss nicht das Ende agiler Methoden bedeuten. Vielmehr ist es eine Chance, den ursprünglichen Kern agiler Ansätze wiederzuentdecken und neu zu beleben. Es geht um kontinuierliches Lernen, ehrliches Feedback und die Bereitschaft, an sich selbst und den eigenen Prozessen zu arbeiten. Für Product Owner heißt das konkret: Die Bereitschaft, Führungsqualitäten zu entwickeln, sich mit den Bedürfnissen des Teams auseinanderzusetzen und die agile Transformation aktiv mitzugestalten. Wer also glaubt, Agilität sei tot, sollte genau hinhören: Agilität lebt dort weiter, wo Menschen mutig Verantwortung übernehmen, wo Teams und Organisationen bereit sind, Veränderungen zu wagen, und wo die Prinzipien nicht als Checkliste, sondern als Leitlinien für echte Zusammenarbeit verstanden werden.…
Tim & Dominique im Gespräch Diesmal geht's um die Jobsuche als Product Owner oder Produktmanager in den aktuellen schwierigen wirtschaftlichen Zeiten. Tim und Dominique beleuchten die momentanen Herausforderungen und geben wertvolle Tipps, wie sich Produktmenschen besser positionieren können, um eine neue Stelle zu finden. Ein Hauptgrund für die schwierige Situation vieler Product Owner ist der wirtschaftliche Druck, dem Unternehmen aktuell ausgesetzt sind. Stellenabbau in agilen Teams und das Zurückfahren von externen Beratungs- und Freelance-Verträgen gehören zu den häufigsten Szenarien. Vor allem Branchen wie die Automobilindustrie oder energieintensive Industrien wie Stahl sind stark betroffen. In vielen Unternehmen wird zusätzlich wieder verstärkt der Fokus auf die Arbeit vor Ort - anstelle von vorrangiger Remote-Tätigkeit - gelegt. Dies schränkt die Flexibilität der Jobsuche wieder oft eher auf einen lokalen Radius ein. Doch auch abseits solcher äußeren Faktoren stehen viele Product Owner vor einer Herausforderung: die eigene Rolle und ihren Wertbeitrag klar zu kommunizieren. Product Owner werden oft lediglich als "Backlog-Schubser" wahrgenommen, wenn es ihnen nicht gelingt, ihre tatsächliche Verantwortung für das Produkt und damit ihren Einfluss auf das Geschäftsergebnis sichtbar zu machen. Es erscheint derzeit besonders wichtig, den eigenen Beitrag zur Vermeidung von Fehlinvestitionen oder zur Steigerung der Produktqualität konkret darzustellen – etwa durch Kennzahlen oder Erfolgsgeschichten. Darüber hinaus raten Tim und Dominique, die eigene Positionierung zu schärfen. Es geht darum, eine klare Expertise zu vertreten - sei es in der Product Discovery, der Delivery oder anderen Schlüsselthemen der Produktentwicklung. Der Aufbau eines gepflegten LinkedIn-Profils ist dafür übrigens unerlässlich; genauso wie die Vernetzung innerhalb der Community. Events wie das Product Lean Coffee oder andere Austauschformate bieten Gelegenheiten, sich zu zeigen, von anderen zu lernen und potenzielle Jobmöglichkeiten zu entdecken. Ein weiterer Tipp: wagt den Blick über den Tellerrand! Die Unterschiede zwischen den Rollen eines Product Owners und eines Produktmanagers sind in vielen Unternehmen fließend. Aber auch Job Beschreibungen links und rechts davon sollten derzeit in Betracht gezogen werden. Wer seine Suche erweitert, hat meist bessere Chancen, eine passende Position zu finden. Zuletzt appellieren Tim und Dominique an die Community und ihr Netzwerk, eine aktive Unterstützung anzubieten – sei es durch das Teilen von Stellenangeboten oder durch die direkte Vermittlung. Gerade in schwierigen Zeiten können solche Verbindungen den entscheidenden Unterschied machen. Abschließend ermutigen sie, trotz aller Herausforderungen optimistisch zu bleiben und auch kleinere Rückschritte in Kauf zu nehmen, um durch diese wirtschaftliche Durststrecke zu navigieren. Denn eines ist klar: Die aktuelle Lage wird nicht von Dauer sein, und eine gute Vorbereitung ist der Schlüssel für zukünftige Chancen bei der Jobsuche als Product Owner und Produktmanager. Hier die Links zu erwähnten Empfehlungen: Link zur Community Reihe "Product Lean Coffee", bei dem Tim und Dominique ehrenamtlich im Orgateam sind: https://www.linkedin.com/groups/12524562/ Buch von April Dunford: Obviously Awesome: How to Nail Product Positioning so Customers Get It, Buy It, Love It Und auch noch die Links zu alten erwähnten Folgen: Jobsituation für Product Owner & digitale Produktmanager Sei dein eigenes Produkt! – Weiterentwicklung für Product Owner Wir hoffen, dass du einige neue Impulse zum Thema Jobsuche aus den Tipps und Empfehlungen von Dominique und Tim ableiten konntest. Bist du selber vielleicht auch aktiv aktiv auf Jobsuche? Welche guten oder schlechten Erfahrungen hast du selber schon dabei gemacht und magst darüber berichten? Wir Produktwerker freuen uns, wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Markus Andrezak im Gespräch mit Oliver Produktstrategie ist ein herausforderndes Thema – unterschiedlichste Strategieansätze, sperrige Begriffe, hohe Erwartungen und der Druck, „richtig“ zu entscheiden, machen es vielen schwer, sich darauf einzulassen. Doch genau hier setzt diese Folge der Produktwerker an. Zusammen mit dem Strategiexperten Markus Andrezak beleuchtet Oliver, wie Product Owner:innen sich effektiv mit Strategieansätzen auseinandersetzen können, ohne in lähmenden Perfektionismus zu verfallen. Was euch immer klar sein sollte: Strategie ist kein abgeschottetes Konzept für eine exklusive Gruppe in einem Unternehmen. Es geht vielmehr darum, klare, bewusste Entscheidungen zu treffen, die Orientierung geben und sich kontinuierlich anpassen lassen. Ansätze wie das Playing-to-Win-Framework von Roger Martin machen dies greifbar. Anstatt einen starren Plan zu schaffen, bietet das Framework die Möglichkeit, flexibel und iterativ zu arbeiten. Ein weiterer wichtiger Punkt ist die regelmäßige Beschäftigung mit Strategie. Markus betont, dass Strategie nicht in einmaligen Offsites entsteht, sondern in kleinen, stetigen Schritten, die Teil des Arbeitsalltags werden. Regelmäßige Reflexionen – zum Beispiel in Meetings oder Sprint Reviews – helfen, Klarheit zu schaffen und die Strategie an den aktuellen Kontext anzupassen. Diese Routine trainiert nicht nur die Fähigkeit, über Strategie zu sprechen, sondern verbessert auch die Kommunikation innerhalb des Teams. Doch es gibt nicht das eine richtige Framework. Vielmehr geht es darum, aus den vielen Strategieansätzen einen Ansatz zu wählen, der zu den eigenen Bedürfnissen und dem Team passt. Ein zentraler Tipp für Product Owner:innen ist, klein anzufangen und iterativ vorzugehen. Das Ziel ist, Strategieansätze so in den Arbeitsalltag zu integrieren, dass sie praktikabel bleiben und echten Mehrwert schaffen. Wer das schafft, wird feststellen, wie sehr eine klare Strategie die tägliche Arbeit erleichtert – sei es bei der Priorisierung des Backlogs oder der Zieldefinition für das Team. Diese früheren Folgen werden in dieser Episode referenziert: Produktstrategie in die Praxis bringen - mit Markus Andrezak The Product Field - Framework The Decision Stack Und diese anderen älteren Folgen können wir in diesem Kontext empfehlen: Eine Produktstrategie entwickeln Von der Produktstrategie zum Product Backlog (mit Roman Pichler) Eine Produktstrategie ohne Canvas erarbeiten (mit Tim Herbig) Frühere Folgen mit Markus Andrezak: Warum scheint die Product Owner Rolle so schwer zu sein? (Folge 3 und immer noch eine der meistgehörten Folgen!) Business- oder Nutzersicht: Welchen Blickwinkel sollte ein PO einnehmen? (neben Markus auch mit Sohrab Salimi - und durch die zwei Experten ausnahmsweise etwas länger als sonst) Wer weitere Fragen an Markus Andrezak hat oder mit ihm in Kontakt treten möchte, erreicht ihn am besten über sein LinkedIn-Profil oder über seine Webseite (ueberproduct.de). Weitere Infos zum Lernen in der "Strategy Collective Cohorte" gibt es bei der überproduct Academy.…
Dominique & Tim im Gespräch In dieser Folge dreht sich alles um ein Thema, das viele Product Owner in der Praxis betrifft: Mehrere Backlogs. Obwohl die Regel im agilen Kontext „Ein Produkt, ein Product Backlog“ lautet, zeigt die Realität oft andere Szenarien. Dominique und Tim erklären wie man als Product Owner damit umgehen kann, wenn man gezwungen ist, mehr als ein Backlog zu verwalten. Bei mehreren Backlogs gibt es einige Herausforderungen. Oft entstehen sie, wenn ein Team an mehreren Produkten oder Services arbeitet, was die Organisation von Prioritäten erschwert. Ein weiteres häufiges Szenario ist die Aufteilung von Aufgaben nach Prozessschritten, etwa ein separates UX-Backlog oder ein Bug-Backlog. Diese unterschiedlichen Quellen und Aufteilungen führen leicht zu einem Verlust der Übersicht. Was ist wirklich wichtig, und welches Backlog hat Vorrang? Product Owner stehen dann oft vor der Frage, wie sie die Transparenz wahren und gleichzeitig strategisch arbeiten können, ohne sich in operativen Details zu verlieren. Die Lösung liegt häufig in einer besseren Organisation und klaren Strukturen. Statt mehrere Backlogs isoliert zu pflegen, empfiehlt es sich, alle Aufgaben in einem System wie Jira zu bündeln und mit Labels oder Filtern zu arbeiten. Dies erleichtert die Priorisierung und schafft eine „Single Source of Truth“ für alle Beteiligten. Zudem kann es sinnvoll sein, Ideen oder potenzielle Features zunächst außerhalb des eigentlichen Product Backlogs zu sammeln. Diese sollten jedoch nicht als zusätzliche Backlogs betrachtet werden, sondern als unterstützende Tools im Discovery-Prozess. Sobald eine Idee reif genug ist, gehört sie ins Product Backlog, um die Arbeit des Teams zu strukturieren und zu priorisieren. Ein weiterer Ansatz ist die Visualisierung der Arbeitsprozesse. Indem die Reise von Ideen und Anforderungen durch den Produktentwicklungsprozess sichtbar gemacht wird, können Teams und Stakeholder besser verstehen, wo welche Prioritäten liegen und welche Schritte nötig sind, um Ziele zu erreichen. Gleichzeitig gilt: Mut zur Einfachheit. Nicht jede Idee oder jedes Feedback muss umgesetzt werden. Wer mutig genug ist, Überflüssiges zu eliminieren, schafft Raum für das Wesentliche. Am Ende gilt vor allem: Für Product Owner, die mit mehreren Produkten und Backlogs arbeiten, ist eine klare Priorisierung entscheidend. Wenn spontane Aufgaben auftreten, hilft eine vorab festgelegte Rangordnung, Konflikte zu vermeiden und die Effizienz zu steigern. Weitere Tipps bekommt ihr in Folgen zu ähnlichen Themen: Product Backlog organisieren ( https://produktwerker.de/product-backlog-organisieren/ ) Features wegwerfen - was braucht es dafür außer Mut? ( https://produktwerker.de/features-wegwerfen/ ) Das Product Goal und seine Bedeutung für Product Owner ( https://produktwerker.de/das-product-goal-und-seine-bedeutung-fuer-product-owner/ ) LeSS aus Product Owner Sicht und aktuelle Skalierungstrends ( https://produktwerker.de/less-als-po/ ) Product Principles ( https://produktwerker.de/product-principles/ )…
Alexej Antropov im Gespräch mit Tim Diesmal dreht sich alles um das spannende Thema AI Tools für Produktmanagement. Tim Klein spricht mit Alexej Antropov, dem Entwickler des sogenannten KI-Radars. Dieses Radar bietet eine strukturierte Übersicht über die Vielzahl von KI-Tools im Produktmanagement und gibt damit eine gute Orientierung. Alexej erklärt, wie er aus seiner Erfahrung und intensiven Recherche diesen Überblick geschaffen hat, der Product Ownern und Produktmanagern einen tollen Marktüberblick der wichtigsten AI Tools in der schnelllebigen Welt der KI-Technologien gibt. Das KI-Radar ist so konzipiert, dass es nach Rollen und Anwendungsfällen in der Produktentwicklung strukturiert ist. Egal, ob man als Designer, Product Owner, Engineer oder im Team tätig ist – das Radar hilft, relevante Tools zu entdecken und deren Reifegrad einzuschätzen. Das Radar umfasst dabei nicht nur etablierte Anwendungen wie Microsoft Copilot, sondern auch experimentelle und vielversprechende Tools. Seine Motivation ist es, die Innovationskraft von Teams zu steigern und das Thema KI pragmatisch und praxisnah in den Arbeitsalltag zu integrieren. Im Gespräch hebt Alexej Antropov hervor, dass die Nutzung von KI-Tools seines Erachtens nicht nur die Effizienz erhöhen kann, sondern auch völlig neue Möglichkeiten eröffnet; etwa beim schnellen Erstellen von Prototypen oder der Analyse von Nutzerinterviews. Ein besonderer Fokus liegt dabei auf der Frage, wie Unternehmen das Potenzial von KI erschließen können, ohne sich in der Komplexität des Themas zu verlieren. Alexej empfiehlt eine iterative Herangehensweise: klein anfangen, experimentieren und lernen. Das Radar selbst ist ein dynamisches Projekt, das sich durch kontinuierliches Feedback (auch von euch!) und neu entdeckte Tools weiterentwickelt. Alexej sieht es als Community-Tool, das also auch durch Beiträge anderer Produktmenschen lebt. Datenschutz und die europäische Gesetzgebung sind für ihn wichtige Kriterien bei der Auswahl der Tools, was das Radar besonders für Unternehmen in der EU attraktiv machen dürfte. Wer sich als Produktmensch mit KI auseinandersetzt, hat die Chance, nicht nur effizienter im Produktmanagement zu arbeiten, sondern auch frühzeitig neue Kompetenzen zu entwickeln. Doch wie fängt man an mit KI zu nutzen? Alexej rät: Einfach Machen! Denn jeder muss irgendwo anfangen. Sein Tipp lautet daher: Geht das Thema einfach in eurem eigenen Tempo an, Hauptsache ihr beginnt damit. Das KI-Radar bietet hierfür eine wertvolle Orientierungshilfe und guten Startpunkt. Es lädt dazu ein, neugierig zu sein und die Möglichkeiten von KI aktiv zu nutzen. Wertvolle Quellen: Das KI-Radar für Produktmanagement & Software-Entwicklung findet ihr in der jeweils aktuellen Fassung hier: https://www.beyondbacklog.de/p/das-ki-radar-fur-produktmanagement-und-software-entwicklung Alexej hat sein KI Radar auch schon mal in einem sehr guten Talk (auf Englisch) vorgestellt. Zu diesem Talk findet ihr hier eine sehr gute und detaillierte Darstellung. Miro im AI Einsatz (inkl. Link zum Prototyping) und den Post von Alexej dazu gibt es hier . Folgende ältere Podcast-Episoden werden von Tim im Gespräch genannt, die super zu dieser Folge passen: AI als Wingman für Product Owner Produktentwicklung von AI Produkten Wie No-Code Tools Produktteams helfen können Guerilla Discovery - wenn der Kontext Product Discovery nicht aktiv unterstützt Wer weitere Fragen an Alexej hat oder ihm selber gute AI Tools für Produktmanagement empfehlen kann, die er noch nicht auf seinem Radar hat, erreicht ihn am besten über sein LinkedIn Profil oder per Mail: alexej@valuerebels.com. Seine Website und vor allem seinen Newsletter findet ihr unter beyondbacklog.de Wir hoffen, dass du einige neue Impulse für deine Arbeit im Produktmanagement rund ums Thema AI Tools aus den Erfahrungen von Alexej Antropov mitnehmen konntest. Welche KI Tools nutzt du selber und für was setzt du sie ein? Wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Dominique & Oliver im Gespräch Das Abbrechen eines Sprints ist ein seltenes, aber einschneidendes Ereignis im agilen Arbeiten. Aber wann ist es sinnvoll, einen Sprint abzubrechen, und was passiert danach? Obwohl Sprints selten abgebrochen werden, kann dies unter bestimmten Umständen hilfreich und richtig sein, um Zeit und Ressourcen zu sparen. Ein zentraler Aspekt rund um die Idee einen Sprint abzubrechen ist die Rolle des Sprintziels. Wenn ein Sprintziel während des Sprints obsolet wird, sei es durch neue Erkenntnisse, technologische Hürden oder strategische Entscheidungen, ist dies ein klarer Grund für einen Sprintabbruch. Zum Beispiel kann eine Änderung auf Kundenseite dazu führen, dass eine zuvor geforderte Funktionalität gar nicht mehr benötigt wird. Oder es stellt sich während der Arbeit heraus, dass eine geplante technische Lösung so nicht umsetzbar ist. In solchen Situationen stehen Product Owner:innen in der Verantwortung, die richtige Entscheidung zu treffen. Schließlich hat nur er oder sie die Befugnis, einen Sprint abzubrechen. Ein Sprintabbruch erfordert jedoch neben Mut auch eine durchdachte Kommunikation. Das Team und andere Stakeholder:innen müssen einbezogen werden, um die Situation zu bewerten und eine fundierte Entscheidung zu treffen. Dabei wird oft deutlich, dass Transparenz und Zusammenarbeit wichtig sind, um den nächsten Schritt zu planen. Nach dem Abbruch des Sprints gilt es dann gemeinsam zu analysieren, welche Arbeitsergebnisse weiterhin verwertbar sind und welche nicht. Eine Retrospektive hilft, die Arbeitsweise zu reflektieren und mögliche Verbesserungen zu identifizieren. Ein Sprintabbruch kann daher auch eine wertvolle Gelegenheit sein, innezuhalten und sich neu auszurichten. Eine klare Orientierung hilft, den nächsten Sprint effektiv zu planen und das Team auf die neuen Ziele einzustimmen. Dominique und Oliver fragen sich in der Folge auch ob Sprints nicht oft genug abgebrochen werden. Oft fehlt es an klar definierten Sprintzielen oder der Fähigkeit, den Fortschritt während des Sprints zu messen. Diese Faktoren können dazu führen, dass Teams zu lange an Aufgaben festhalten, die nicht den richtigen Mehrwert für Nutzer:innen bieten. Am Ende bleibt, dass es für Product Owner:innen essenziell ist, die Auswirkungen eines Sprintabbruchs zu berücksichtigen und die verbleibende Zeit sinnvoll zu nutzen. Der Abbruch eines Sprints ist kein Zeichen von Scheitern, sondern ein Schritt, der dabei hilft, den Fokus auf das Wesentliche zu richten. Ein Sprintabbruch ist selten. Daher interessiert es uns sehr, wie eure Erfahrungen dabei sind. Habt ihr bereits einen Sprint abgebrochen und was habt ihr dabei gelernt? Was könnt ihr anderen mit auf den Weg geben? Schreibt es gerne in den Kommentaren des zur Folge gehörenden Blogbeitrags ( https://produktwerker.de/wann-breche-ich-einen-sprint-ab-und-was-mache-ich-danach/ ) oder auf LinkedIn ( https://www.linkedin.com/company/produktwerker/) .…
Bernd Joussen im Gespräch mit Tim In dieser Folge geht's darum Konflikte mit Stakeholdern zu meistern. Konflikte sind im Produktmanagement fast unvermeidlich, da unterschiedliche Interessengruppen oft widersprüchliche Ziele verfolgen. Bernd Joussen, ein erfahrener Coach für Teamentwicklung und Konfliktmanagement (und zugleich auch Konflikt-Mediator), teilt im Gespräch mit Tim seine Einsichten darüber, wie Product Owner solche Spannungen und konfliktbeladenen Situationen erfolgreich handhaben können. Ein Konflikt, so erklärt Bernd, entsteht, wenn zwei oder mehr Parteien unterschiedliche Interessen verfolgen und mit ihren Ansprüchen bzw. Erwartungshaltungen aufeinandertreffen. Er betont die Bedeutung einer bewussten Abgrenzung zwischen strukturellen und zwischenmenschlichen Konflikten. Während die einen oft aus widersprüchlichen Unternehmenszielen resultieren, etwa durch fehlende strategische Orientierung oder technische Limitierungen, betreffen die anderen eher persönliche oder teaminterne Spannungen. In Organisationen gibt es typische Konfliktfelder, wie das Ringen um begrenzte Ressourcen oder unterschiedliche Prioritäten, etwa zwischen Marketing und Produktentwicklung. Solche Spannungen verschärfen sich oft, wenn Stakeholder ihre Interessen stark durchsetzen wollen. Hier können Product Owner ansetzen, indem sie eine Kultur der Empathie und des gegenseitigen Verständnisses fördern. Bernd empfiehlt das Johari-Fenster hierfür als hilfreiches Tool, das den Teammitgliedern dabei hilft, blinde Flecken aufzudecken und durch bewusstes Teilen eigener Bedürfnisse Vertrauen zu stärken. Ein weiterer wertvoller Tipp von Bernd ist die sogenannte Konflikt-Map, ein visuelles Werkzeug, das die Beziehungen und Spannungen zwischen verschiedenen Akteuren anschaulich darstellt. Mit Blitzen und Pfeilen lassen sich so problematische Verbindungen oder Kommunikationslücken verdeutlichen. Diese Methode schafft Klarheit und hilft dem gesamten Team, Konfliktmuster zu erkennen und gezielt anzugehen. Für Bernd ist es wichtig eine gesunde Streitkultur zu pflegen. Konflikte können das Team stärken, wenn sie konstruktiv geführt werden, denn sie bieten Raum für Innovation und Weiterentwicklung. Product Owner können diese Dynamik unterstützen, indem sie regelmäßig Feedback einholen und lernen, souverän mit Kritik umzugehen. Hierfür ist das Buch "Radical Candor" von Kim Scott hilfreich, das praxisnahe Ansätze für eine ehrliche und respektvolle Kommunikation vermittelt. Als praxisnahen Tipp für alle, die ihre Zusammenarbeit verbessern wollen stellt Tim das „How-to-work-with-me“-Dokument vor. Hierbei handelt es sich um eine Art "Bedienungsanleitung für mich selbst", die persönliche Präferenzen und Bedürfnisse beschreibt, damit das Team besser auf mich (und meine Eigenarten und Erwartungshaltungen an den Umgang mit mir) eingehen kann. Dies stärkt nicht nur die Kommunikation, sondern kann auch helfen, potenziellen Konflikten präventiv entgegenzuwirken. Diese Folge mit Bernd Joussen verdeutlicht, dass Konflikte mit Stakeholdern zum Alltag eines Product Owners gehören und nicht vermieden, sondern konstruktiv genutzt werden sollten. Ihr als Product Owner solltet euch daher nicht scheuen, externe Unterstützung durch Coaches oder Mediatoren wie Bernd hinzuzuziehen, um die Konfliktlösung zu erleichtern und die Zusammenarbeit im Team zu fördern. Diese früheren Folgen werden in dieser Episode referenziert: Umgang mit schwierigen Stakeholdern Herausforderungen zwischen Product Owner und Developer (frühere Folge mit Bernd Joussen) Stakeholder Community Konflikte zwischen Scrum Master und Product Owner Bernd empfiehlt im Gespräch folgende Tools und Bücher: Johari Fenster Conflict Map Birgit Schumacher: Psychologische Sicherheit Manfred Prior: MiniMax-Interventionen Kim Scott: Radical Candor Friedrich Glasl: Konfliktmanagement Lyssa Adkins: Market of Skills (aus ihrem Buch " Coaching Agile Teams "). Hier eine andere Erklärung zum Market of Skills . Tim erwähnt noch das "How To Work With Me"-Manual, welches auf der Idee von Claire Hughes Johnson ("How to work with Claire") basiert. Weitere Erklärungen gibt's hier . Wer weitere Fragen an Bernd Joussen hat oder mit ihm in Kontakt treten möchte, erreicht ihn am besten über sein LinkedIn-Profil oder über seine Webseite ( der-teamdynamo.de ). Wir hoffen, dass du einige neue Impulse zum Thema Konflikte mit Stakeholdern aus den Erfahrungen von Bernd Joussen ableiten konntest. Welche typischen Konflikte mit Stakeholdern hast du selber und wie gehst du damit um? Wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
D
Die Produktwerker
Oliver & Tim im Gespräch n dieser Podcastfolge widmen sich Oliver & Tim dem Thema Produktrisiken und beleuchten, welche Herausforderungen Product Owner im Hinblick auf die Risikobetrachtung meistern sollten. Jede Produktentwicklung beinhaltet Risiken mit denen man sich auseinandersetzen und bewusst mit ihnen umzugehen muss. Als Product Owner liegt es im Kern ihrer Verantwortung, mögliche Risiken frühzeitig zu erkennen und Strategien zu entwickeln, um diese zu minimieren. Die beiden sprechen über die Einteilung von Produktrisiken in vier Kategorien: Usability-Risiken (Nutzbarkeit für den Kunden), Value-Risiken (Mehrwert für den Kunden), Business Viability-Risiken (wirtschaftliche Tragfähigkeit) und Feasibility-Risiken (Machbarkeit). Es ist entscheidend, als Product Owner ein Bewusstsein für diese unterschiedlichen Risikobereiche zu entwickeln. Das Verständnis der Kundenbedürfnisse und die fortlaufende Evaluation des Marktes helfen, mögliche Value-Risiken zu reduzieren. Denn nur ein Produkt, welches tatsächlich einen Mehrwert bietet, hat langfristig Bestand. Bei den Business Viability-Risiken liegt der Fokus auf der wirtschaftlichen Tragfähigkeit des Produkts. Ein Produkt mag den Nutzern gefallen und technisch machbar sein, dennoch kann es an einem rentablen Geschäftsmodell scheitern. Es ist dabei von entscheidender Bedeutung, die strategische Ausrichtung des Unternehmens zu berücksichtigen und sicherzustellen, dass das Produkt langfristig den wirtschaftlichen Erfolg unterstützt. Ein wichtiger Aspekt, der in dieser Folge angesprochen wird, ist die Notwendigkeit, über rein technische Risiken hinaus auch ethische Aspekte zu berücksichtigen. Hier kommen Tim und Oliver auf das sogenannte ethische Risiko zu sprechen, bei dem es darum geht, ob ein Produkt moralisch vertretbar ist und im Einklang mit den ethischen Grundsätzen der Organisation steht. Kontinuierliche Product Discovery und die enge Zusammenarbeit mit Stakeholdern können dabei helfen, Produktrisiken frühzeitig zu identifizieren und durch gezielte Tests und Experimente zu mindern. Produktideen werden in der Entstehungsphase auf Annahmen geprüft und in Hypothesen überführt, um auf Basis der Ergebnisse Entscheidungen zu treffen, bevor es in die Product Delivery geht. Dabei kann die Zusammenarbeit in einem sogenannten „Product Trio“ aus Product Owner, Designer und Engineers wertvolle Perspektiven für die Risikobetrachtung eröffnen. Diese Folge bietet praxisnahe Einblicke und viele anschauliche Beispiele, wie Product Owner im täglichen Umfeld Produktrisiken bewerten und Strategien entwickeln können, um Unsicherheiten zu managen und die Erfolgsaussichten ihrer Produkte zu steigern.…
Denny Meier im Gespräch mit Tim Wie sieht die Jobsituation für Product Owner und digitale Produktmanager zum Ende des Jahres 2024 aus? Tim spricht in dieser Episode mit Recruiting-Experte Denny Meier über die aktuelle Marktlage und die Trends für Product Owner und digitale Produktmanager. Denny Meier ist tief drin im Markt für Product Owner und Produktmanager, da er sich schon vor Jahren auf die Vermittlung und Suche von Festangestellten mit solchen Expertisen spezialisiert hat. Denny taucht erstmal tief in die Zahlenwelt ein und bespricht mit Tim u.a., wie sich die Jobtitel und die Anforderungen in diesen Rollen verändern. Dabei geht es aber auch um die Entwicklung des Rollenverständnisses: weg von der reinen Verwaltung des Backlogs hin zu einem stärker wertorientierten Ansatz. Ein weiterer Schwerpunkt der Folge liegt auf der Gehaltssituation und auch dem Gender Pay Gap: wie sehen die aktuellen Gehaltszahlen aus, und welche Unterschiede bestehen zwischen den Geschlechtern? Spannend ist dabei auch der Vergleich bzw. Entwicklung zur Gehalts- und Jobsituation für Product Owner im Jahr 2020, als Denny Meier schon mal in unserem Podcast zu Gast war. Für Senior-Positionen zeigt Denny die zunehmende Bedeutung organisatorischer Themen, Führungskompetenzen und die auch Organisationsentwicklung bei der Suche nach Kandidatinnen und Kandidaten auf. Denny teilt auch Einblicke in die verschiedenen Branchen, die besonders stark nach Talenten suchen. Abschließend gehen die beiden darauf ein, welchen Hintergrund die Leute in diesen Rollen häufig mitbringen und geben wertvolle Tipps für alle, die sich auf der Suche nach einer passenden Position im Produktmanagement befinden. Natürlich ist die Jobsituation für Product Owner und digitale Produktmanager derzeit etwas angespannter, aber gute Chancen gibt es für spannende Profile nach wie vor. Gute Leute werden halt irgendwie immer gesucht. Auf diese früheren Folgen wird im Laufe der Episode verwiesen: Sich als Product Owner auf die Bewerbung vorbereiten - Gast: Denny Meier Der Arbeitsmarkt für Product Owner & Product Leader (Juli 2020) - Gast: Denny Meier AI als Wingman für Product Owner Sei dein eigenes Produkt! – Weiterentwicklung für Product Owner Wenn ihr in den direkten Austausch mit Denny kommen wollt oder weitere Fragen habt, erreicht ihr ihn am besten über sein LinkedIn-Profil . Natürlich könnt ihr ihn auch gerne als suchendes Unternehmen oder als suchende Kandidatin bzw. Kandidat direkt via LinkedIn ansprechen. Wir hoffen, dass du wichtige Anstöße und Infos aus den Erfahrungen, die Denny Meier mit uns geteilt hat, ableiten konntest. Wie guckst du aktuell auf den Jobmarkt für Product Owner und Produktmanager? Wir Produktwerker freuen uns, wenn du deine Gedanken zu diesem Thema mit uns und den anderen Hörerinnen und Hörern teilst. Welche Info hat dich besonders überrascht oder was siehst du anders? Wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Dominique & Oliver im Gespräch In dieser Folge des Produktwerker-Podcast dreht sich alles um Continuous Delivery aus der Perspektive eines Product Owners. Dominique und Oliver beleuchten die Unterschiede zwischen Continuous Integration, Continuous Delivery und Continuous Deployment und tauschen sich darüber aus, wie wichtig diese Praktiken auch für Produktmenschen sind, um kontinuierlich Mehrwert zu liefern. Continuous Delivery hingegen ermöglicht im Gegensatz zu früher üblichen umfangreichen Releases, kleinere Änderungen regelmäßig auszuliefern und diese frühzeitig in produktionsnahen Umgebungen zu testen. Einer der wichtigsten Argumente für Continuous Delivery ist die Risikominimierung. Durch kontinuierliches Testen in Staging-Umgebungen lassen sich potenzielle Probleme frühzeitig erkennen und beheben, bevor sie live gehen. Dies erhöht nicht nur die Qualität, sondern schafft auch Sicherheit für den Product Owner und das Team. Dominique und Oliver diskutieren in diesem Kontext den Einsatz von Feature-Toggles, mit denen Funktionen gezielt für bestimmte Nutzergruppen aktiviert werden können, um Feedback zu erhalten und die Einführung neuer Features zu kontrollieren. Durch Continuous Delivery wird der Übergang von der Entwicklung zur Auslieferung fließender und transparenter, was wiederum die Zusammenarbeit und Abstimmung mit Stakeholdern erleichtert. Continuous Delivery bekomme ich als Product Owner nicht geschenkt, es erfordert eine Investition in technische Infrastrukturm welche letztendlich die Produktqualität und die Liefergeschwindigkeit verbessert. Dabei sollte das Team regelmäßig reflektieren, wie viel Aufwand bei der Integration und Auslieferung erforderlich ist, um den Nutzen einschätzen zu können. Continuous Delivery hilft somit, kontinuierlich wertvolle und getestete Produktinkremente bereitzustellen und ermöglicht es Product Ownern, flexibler auf Veränderungen zu reagieren und schneller auf die Bedürfnisse der Nutzer einzugehen.…
Deniz Dogan im Gespräch mit Tim In dieser Folge geht es um die Herausforderungen und Chancen des Produktmanagements in regulierten Branchen. Tim spricht heute mit Deniz Dogan, Product Management Consultant bei den Product People, über die spezifischen Anforderungen, die auf Product Owner in regulierten Umfeldern zukommen. Regulierung stellt natürlich häufig eine Hürde dar, weil sie viele Freiheiten während der Produktentwicklung einschränkt. Doch dies sollte nicht nur als Beschränkung gesehen werden. Vielmehr bietet die Gesetzeslage oft auch Spielraum, wie Regelungen umgesetzt werden, was Raum für kreative Lösungen schafft. Ein Beispiel in dieser Folge ist der Digital Services Act (DSA), bei dem zwar Vorgaben zu Transparenz und Meldemöglichkeiten erfüllt werden müssen, aber nicht festgelegt ist, wie dies genau zu geschehen hat. Hier zum Beispiel hat Deniz Dogan durch sorgfältige Analyse der Vorgaben und enge Zusammenarbeit mit dem Compliance-Team innovative Ansätze gefunden, um Anforderungen effizient zu erfüllen, ohne unnötigen Aufwand zu erzeugen. Die enge Zusammenarbeit mit Compliance-Teams ist besonders wichtig, um das Produktmanagement in regulierten Branchen zu erleichtern. Deniz betont in dieser Folge, wie wichtig es ist, frühzeitig und proaktiv den Dialog mit diesen Abteilungen zu suchen. Oft wird aus Unsicherheit lieber ein konservativer Ansatz gewählt, der jedoch nicht immer nötig ist. Indem Product Owner die gesetzlichen Rahmenbedingungen genau verstehen und kritisch hinterfragen, können sie unnötige Aufwände vermeiden und gleichzeitig rechtskonform bleiben. So wird aus einem vermeintlichen Hindernis eine Gelegenheit für Produktverbesserungen und damit eine echte Chance. Besonders in regulierten Branchen zeigt sich zudem, dass Vorschriften oft nicht eindeutig sind, was Raum für Interpretation lässt. Dies führt zu Ambiguität, die zwar zusätzliche Komplexität schafft, aber auch Gestaltungsspielräume eröffnet. Dies bietet eine Chance, Wettbewerbsvorteile zu erzielen, indem Unternehmen die Anforderungen nicht nur erfüllen, sondern die Art wie sie die Erfüllung dieser Regulation meistern zu einem Selling Point machen. Ein Beispiel hierfür ist die Barrierefreiheit, bei der sich Unternehmen durch besonders proaktive Maßnahmen im Markt differenzieren können. Letztlich kommt es darauf an, als Product Owner nicht nur die Vorschriften zu erfüllen, sondern den Mehrwert darin zu erkennen, wie ein Produkt dadurch besser und sicherer gestaltet werden kann. Wer bereit ist, die Regeln genauer unter die Lupe zu nehmen und in den Dialog mit den richtigen Stakeholdern zu gehen, kann auch in streng regulierten Märkten innovativ agieren und sich einen Vorsprung verschaffen. Im Produktmanagement in regulierten Branchen geht es also nicht nur darum, sich an Gesetze zu halten, sondern diese auch als Chance zu nutzen, Produkte nachhaltig besser zu machen. Diese früheren Folgen werden in dieser Episode referenziert: Guerilla Discovery - wenn der Kontext Product Discovery nicht aktiv unterstützt Barrierefreiheit von digitalen Produkten Umgang mit schwierigen Stakeholdern Wer weitere Fragen an Deniz hat oder mit ihm in Kontakt treten möchte, erreicht ihn am Besten über sein LinkedIn-Profil oder über die Product People. Von Deniz Dogan gibt es zudem auch ein englisches Webinar der Product People zum Thema ” Product Management in regulated industries: Navigating the Digital Service Act ” Wir hoffen, dass du einige neue Impulse zum Thema reguliertes Umfeld aus den Erfahrungen von Deniz Dogan ableiten konntest. Bist du selber vielleicht auch im Produktmanagement und von Regulation betroffen? Wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Dominique & Oliver im Gespräch In dieser Folge dreht sich alles um das Arbeiten als Product Owner im Home Office. Seit der Corona-Pandemie ist Home Office für viele POs zur Normalität geworden, was sowohl Chancen als auch Herausforderungen mit sich bringt. Oliver und Dominique diskutieren, wie sich die Verantwortung eines Product Owners durch die veränderten Arbeitsbedingungen verschoben hat und welche Auswirkungen dies auf die tägliche Arbeit hat. Eine der größten Veränderungen betrifft die Kommunikation besonders mit dem eigenen Team. Obwohl die virtuelle Kommunikation via Slack oder Videokonferenzen viele spannende Möglichkeiten bietet, gibt es Aspekte, die im Home Office schwerer umsetzbar sind. Spontane Gespräche oder das schnelle „Zurufen“ einer Frage im Teamraum vor Ort fehlen, was den Austausch im Team verlangsamen kann. Product Owner müssen darüber hinaus darauf achten, dass trotz Remote-Arbeit keine wichtigen Informationen verloren gehen. Andererseits bietet das Home Office aber auch einige Vorteile: Die Flexibilität ermöglicht es, sich besser auf bestimmte Aufgaben zu fokussieren und tiefere, ungestörte Arbeit zu leisten. Eine weitere kommunikative Herausforderung ist es, die Beziehung zu den Stakeholdern zu pflegen. Im Büro gibt es diverse Möglichkeit sich informell auszutauschen – etwa an der Kaffeemaschine – während im Home Office solche Gelegenheiten fehlen. Hier sind kreative Ansätze gefragt, um den Kontakt nicht nur formell, sondern auch auf einer persönlichen Ebene aufrechtzuerhalten. Ein „Stakeholder-Daily“ könnte beispielsweise helfen, die Entscheidungsprozesse zu beschleunigen, indem regelmäßige kurze Meetings stattfinden. Doch Arbeiten im Home Office bietet nicht nur Hürden, sondern auch einige neue Chancen. Product Owner können durch die zunehmende Flexibilität Jobmöglichkeiten im gesamten deutschsprachigen Raum, oder sogar darüber hinaus, wahrnehmen. Zudem verbessern digitale Tools wie Miro oder Confluence die Zusammenarbeit und die Dokumentation. Das Arbeiten im virtuellen Raum ermöglicht es, transparenter zu agieren und Prozesse effizienter zu gestalten. Ein großer Vorteil des Home Offices ist auch die Möglichkeit, den eigenen Arbeitsrhythmus flexibler zu gestalten. Product Owner können tiefer in Aufgaben eintauchen, ohne von äußeren Faktoren im Büro abgelenkt zu werden. Auf eines sollte man aber achten: Die klare Trennung zwischen Arbeit und Privatleben fällt oft schwer, besonders wenn man nicht in einem separaten Arbeitszimmer, sondern vielleicht am Küchentisch arbeitet. Insgesamt gibt diese Folge praktische Tipps, wie du die Herausforderungen des Home Offices meistern kannst. Als PO solltest du deinen Arbeitsalltag aktiv gestalten und nicht einfach nur den Umständen ausgeliefert sein.…
D
Die Produktwerker
Peter Rochel im Gespräch mit Tim In der aktuellen Folge des Produktwerker-Podcasts dreht sich alles um ein spannendes Thema für Product Owner: die Progress Design Map. Tim hat erneut den Experten Peter Rochel von UXTO Solutions zu Gast, der zusammen mit seinem Team eine Weiterentwicklung des klassischen Value Proposition Canvas vorstellt. Mit der Progress Design Map will UXTO den Jobs-to-de-Done Prozess auf ein neues Level heben, indem die Herausforderungen und Grenzen des Value Proposition Canvas im Rahmen des "Wheel of Progress" angegangen werden. Peter gibt zunächst eine kurze Einführung in das Jobs-to-be-Done-Konzept, das in der Produktentwicklung dafür sorgt, die Bedürfnisse und Aufgaben der Kunden besser zu verstehen. Wie Peter erklärt, war das Value Proposition Canvas bislang zwar ein guter Anfangspunkt, aber in der Praxis stößt es oft an seine Grenzen. Besonders bei der Frage, wie ein Produkt über verschiedene Entwicklungsphasen hinweg optimal gestaltet und am Markt positioniert werden kann, hatte der Canvas Schwächen gezeigt. Hier setzt die Progress Design Map an. Sie ist speziell darauf ausgelegt, die Erkenntnisse aus Kundeninterviews und der kontinuierlichen Marktforschung zu strukturieren und direkt in die Produktentwicklung einzubringen. Im Gegensatz zum herkömmlichen Value Proposition Canvas berücksichtigt die neue Methode die fünf unterschiedlichen Phasen, die ein Kunde durchläuft – die Passive Suche, Aktive Suche, Entscheidung, Erste Nutzung und Wiederholte Nutzung. Peter Rochel erklärt, dass es darum geht, gezielt zu entscheiden, welche Features und Funktionen in welchem Entwicklungsstadium des Produkts priorisiert werden. Statt wahllos alles zu entwickeln, liegt der Fokus darauf, die wertvollsten Fortschritte für den Kunden zu erzielen und dabei nicht unnötig Ressourcen zu verschwenden. Gerade in den frühen Phasen, so Peter, sei es wichtig, den Kunden nicht mit zu vielen Details zu überfordern. Erst wenn ein konkreter Bedarf erkennbar ist, wird das Produkt sukzessive weiterentwickelt. Tim und Peter diskutieren auch die Bedeutung von Ereignissen, die das Kundenverhalten beeinflussen. Sie sprechen über die "limitierenden Kontexte", in denen ein Produkt genutzt wird, und wie diese den Entwicklungsprozess beeinflussen sollten. Peters Beispiel hier ist die Nutzung einer App für urbane Mobilität bei schlechtem Netzempfang oder Regen. Hier wird schnell klar, dass es nicht nur um technische Features geht, sondern darum, wie diese in spezifischen Nutzungsszenarien wirklich einen Fortschritt für den Nutzer bringen. Ein gutes Problemverständnis ist entscheidend, um nicht nur Produkte, sondern echte Lösungen zu liefern. Peter plädiert dafür, frühzeitig Feedback von echten Nutzern zu sammeln und dieses gezielt in die Weiterentwicklung einfließen zu lassen. So wird vermieden, dass sich ein Backlog mit irrelevanten Features füllt, die später mühsam wieder aussortiert werden müssen. Für alle, die tiefer in das Thema einsteigen möchten, empfiehlt Peter die Nutzung der Progress Design Map, welche bald unter Creative Commons frei verfügbar ist. Es ist ein starkes Werkzeug, um die komplexen Zusammenhänge im Innovationsprozess besser zu strukturieren und als Team effizienter zu arbeiten. Die Progress Design Map ist ein Schritt in Richtung einer noch nutzerzentrierteren und datengetriebenen Arbeitsweise. Hört rein und erfahrt, wie ihr eure Produktentwicklung optimieren und eure Produkte noch erfolgreicher machen könnt! Die frühere Folge zur "Jobs-to-be-Done" Methode mit Gast Peter Rochel findet ihr hier: Mit "Jobs to Be Done"-Interviews zum besseren Kundenverständnis Wenn du weitere Fragen an Peter Rochel hast oder mit ihm in Kontakt treten möchtest, erreichst du ihn ganz einfach über sein LinkedIn-Profil . Wir hoffen, dass du einige neue Impulse zum Thema Kundenverständnis aus den Erfahrungen von Peter Rochel ableiten konntest. Bist du selber vielleicht auch aktiv in der Nutzung des Value Proposition Canvas? Dann schau dir mal die Progress Design Map als spannende Weiterentwicklung an. Wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Oliver & Dominique im Gespräch In dieser Folge unseres Podcasts dreht sich alles um die Herausforderungen und Best Practices rund um die Releaseplanung, insbesondere der Planung und Umsetzung großer Releases. Wir beleuchten dabei, wie wichtig es für Product Owner ist, die Releaseplanung bewusst und vorausschauend zu gestalten. Gerade in agilen Teams, die nach Scrum arbeiten, gibt es oft das Missverständnis, dass am Ende eines jeden Sprints ein Release erfolgen muss, obwohl es doch lediglich heißt, dass das Inkrement potentiell auslieferungsfähig ist (es erfüllt laut Scrum Guide die Definition of Done). Es ist also möglich das Ende eines Sprints und den Zeitpunkt eines Releases voneinander zu entkoppeln. Denn nicht jede potenziell auslieferbare Funktion muss ja sofort live gehen. Ein zentrales Thema ist diesmal die Frage, wann ein Release sinnvoll ist. Product Owner müssen einen klaren Mehrwert für die Nutzer innen identifizieren , bevor sie den finalen Schritt gehen. Ein Release ist mehr als nur das Bereitstellen von neuen Funktionen. Es erfordert eine detaillierte Planung, um den tatsächlichen Nutzen und Wert zu maximieren. Dabei gilt es, Abhängigkeiten zwischen verschiedenen Teams und Systemen im Auge zu behalten. Ein weiterer wichtiger Punkt, den wir in der Folge ansprechen, ist die Kommunikation während der Releaseplanung. Sowohl intern als auch extern müssen alle Beteiligten – von Entwickler innen über Support-Teams bis hin zu Stakeholder:innen – auf den gleichen Wissensstand gebracht werden. Oft gibt es während eines Releases eine Downtime, die Nutzer innen vorher mitgeteilt werden muss. Hierbei sollte der Zeitpunkt für das Release so gewählt werden, dass möglichst wenige Nutzer innen betroffen sind, wie etwa mitten in der Nacht. Wir diskutieren auch, wie man mit Problemen umgeht, die während eines Releases auftreten können. Es ist wichtig, dass bereits vor dem Release einen klaren Entscheidungsprozess definiert wird, falls unerwartete Schwierigkeiten auftreten. Für große Releases empfiehlt sich außerdem das Konzept des Feature-Toggles, mit dem bestimmte Funktionen gezielt aktiviert oder deaktiviert werden können, um potenzielle Probleme schnell zu identifizieren. Ehrlicherweise sind wir eher Freunde von kontinuierlicher Bereitstellung von Produktveränderungen statt von großen Releases. Aber auch unserer Erfahrung nach gibt es manchmal einfach gute Gründe. Wir würde uns aber wirklich über eure Erfahrungen rund um die Planug großer Releases freuen, denn so können wir besser voneinander lernen. Teilt eure Erfahrungen und Tipps gerne auf unserer Website in den Kommentaren. :-)…
Marcel Bertram & Daniel Diener im Gespräch mit Dominique Diesmal geht es um ein Thema, das in der digitalen Produktentwicklung noch oft unterschätzt wird: Barrierefreiheit. Mit den Experten Marcel Bertram und Daniel Diener, beide Gründer von A11YPLAN, sprechen wir in dieser Folge über die Bedeutung von Barrierefreiheit in digitalen Produkten und warum sie nicht nur für Menschen mit Behinderungen relevant ist. Barrierefreiheit ist nämlich weit mehr ist als eine rechtliche Notwendigkeit. Barrierefreie Produkte schaffen generell bessere Nutzererlebnisse. Sie sorgen dafür, dass keine Stolpersteine im Weg stehen, wenn Menschen digitale Services nutzen möchten. Egal ob jemand blind ist, vorübergehend eine Einschränkung hat (weil man beispielsweise ein Kind auf einem Arm trägt) oder schlichtweg unter schlechten Lichtverhältnissen arbeitet – ein gutes UX-Design und barrierefreie digitale Produkte machen das Leben leichter. Und das betrifft am Ende uns alle, denn jeder von uns kann in Situationen kommen, in denen eine Website oder App schwerer zugänglich wird. Auch Dinge wie eine langsame Internetverbindung oder schlecht designte mobile Seiten können Hindernisse darstellen und das kennen wir wahrscheinlich alle irgendwo. Barrierefreiheit bedeutet also nicht nur, sich auf spezielle Nutzergruppen zu konzentrieren, sondern das gesamte Produkt so zu gestalten, dass es für jeden einfach nutzbar ist. Seit der Einführung des European Accessibility Act, der ab Juni 2025 gilt, müssen Unternehmen, die digitale Produkte oder Services anbieten, barrierefreie Angebote schaffen – und das nicht nur für neue Websites, sondern auch für bestehende, wenn sie wesentliche Aufrufe erfahren. Doch Marcel und Daniel machen klar: Barrierefreiheit ist nicht nur eine Frage des Gesetzes. Sie ist vielmehr ein klarer Business Case: Gut zugängliche Produkte reduzieren Supportanfragen, erhöhen die Kundenzufriedenheit und steigern den Umsatz. Die Berücksichtigung von Barrierefreiheit in der Produktentwicklung spart nicht nur Kosten, sondern ist auch eine langfristige Investition in die Kundenzufriedenheit. Für Product Owner, die sich bisher noch nicht intensiv mit dem Thema beschäftigt haben, empfehlen Marcel und Daniel, mit einer Bestandsaufnahme zu beginnen. Hier gibt es bereits zahlreiche Tools wie Google Lighthouse oder Deque, die automatisierte Prüfungen durchführen können. Doch das allein reicht nicht: Eine manuelle Überprüfung und echte Nutzertests mit Menschen, die Einschränkungen haben, sind unerlässlich, um sicherzustellen, dass das Produkt wirklich barrierefrei ist. Am Ende der Folge, wie immer, geben die beiden Experten praktische Tipps für den Einstieg in die Welt der Barrierefreiheit. Empathie ist dabei ein zentraler Punkt: Product Owner sollten sich aktiv mit der Frage auseinandersetzen, wie Menschen mit Einschränkungen ihre Produkte nutzen. Eine einfache Übung kann schon sein, auf dem eigenen Smartphone die Barrierefreiheits-Einstellungen zu testen oder Menschen aus dem eigenen Umfeld dabei zu beobachten, wie sie mit den Produkten interagieren. Barrierefreiheit ist keine Herausforderung, die Unternehmen vor sich herschieben sollten. Sie ist ein Schlüssel zu besseren Produkten, zufriedeneren Nutzern und langfristigem Erfolg. Wenn du als Product Owner dein Produkt auf das nächste Level heben willst, führt kein Weg an einer barrierefreien Gestaltung vorbei.…
Dominique & Tim im Gespräch In dieser Folge geht es um ein Thema, das viele Product Owner kennen, aber nicht immer richtig verstehen: Business KPIs. Welche Kennzahlen sind für die Arbeit eines Product Owners tatsächlich relevant und wie beeinflussen sie die Produktentwicklung sowie den Erfolg eines Unternehmens? Gemeinsam sprechen Dominique und Tim über die verschiedenen Metriken, die Product Owner kennen sollten, um fundierte Entscheidungen treffen zu können – von der Conversion Rate bis hin zum Customer Lifetime Value (CLV). Die Frage, die immer wieder aufkommt: Welche KPIs sind für mich als Product Owner wirklich relevant? Business KPIs sind nicht einfach nur eine Kennzahl, sondern ein besonderer Indikator, der hilft, Entscheidungen zu treffen. KPIs sind also mehr als nur Zahlen – sie geben Aufschluss darüber, wie das Produkt genutzt wird und wo Handlungsbedarf besteht. Ein Beispiel ist die Conversion Rate (CR). Sie misst, wie viele Nutzerinnen und Nutzer von einem bestimmten Punkt (z. B. Besuch der Webseite) zu einem gewünschten Endzustand (z. B. Kauf) wechseln. Diese Kennzahl ist nicht nur im Marketing relevant, sondern gibt auch wichtige Einblicke in die Nutzung eines Produkts. Ähnlich verhält es sich mit der Churn Rate, die anzeigt, wie viele Nutzer das Produkt wieder verlassen – ein kritischer Indikator für die langfristige Bindung. Besonders spannend ist die Diskussion um den Umsatz (Revenue) und den Unterschied zwischen Umsatz und Gewinn. Viele Unternehmen konzentrieren sich stark auf steigende Umsatzzahlen, doch wie Tim klarstellt, sind hohe Umsätze natürlich nichts wert, wenn die Kosten explodieren. Hier wird deutlich, wie wichtig es ist, auch auf andere Kennzahlen wie die Customer Acquisition Costs (CAC) zu achten, die die Kosten für die Gewinnung neuer Kunden darstellen. Werden diese Kosten zu hoch, kann das Wachstum langfristig nicht nachhaltig sein. Die Customer Retention Rate (CRR) ist ein weiterer KPI, die für Product Owner von großer Bedeutung ist. Sie zeigt, wie gut es einem Unternehmen gelingt, bestehende Kunden zu halten. Gerade in der digitalen Produktwelt, wo es oft günstiger ist, bestehende Kunden zu binden, anstatt neue zu akquirieren, kann diese Kennzahl entscheidend sein. Besonders spannend ist die Diskussion über den Customer Lifetime Value (CLV). Diese Kennzahl gibt an, wie viel ein Kunde im Laufe seiner gesamten Beziehung mit einem Unternehmen wert ist. Für Product Owner, die Subscription-Modelle oder wiederkehrende Käufe managen, ist dies eine zentrale Größe. Sie hilft dabei, langfristig zu planen und zu verstehen, wie viel ein Unternehmen in die Akquise eines Kunden investieren kann, ohne am Ende Verluste zu machen. Besonders deutlich wird im Gespräch der beiden, wie wichtig es ist, den Zusammenhang zwischen diesen Business KPIs und der täglichen Arbeit als Product Owner zu verstehen. Es reicht nicht aus, nur zu wissen, was ein CLV oder eine Conversion Rate ist – man muss auch in der Lage sein, diese Kennzahlen in konkrete Handlungen umzusetzen, sei es durch die Optimierung von Prozessen oder durch die Anpassung von Produkten. Business KPIs sind für Product Owner also mehr als bloße Zahlen. Sie sind der Kompass, der dabei hilft, den Kurs eines Produkts zu bestimmen und fundierte Entscheidungen zu treffen. Dabei ist es wichtig, die KPIs nicht isoliert zu betrachten, sondern immer im Zusammenhang mit der übergeordneten Strategie des Unternehmens. Product Owner sollten den Mut haben, Fragen zu stellen, wenn sie auf eine unbekannte Begriffe oder Kennzahlen stoßen, und sich die Zeit nehmen, diese zu verstehen. Denn wie Tim und Dominique in der Episode betonen: Oftmals wissen auch die anderen Stakeholder nicht genau, worum es bei einer bestimmten KPI geht – ein klarer Kommunikationsprozess hilft allen Beteiligten, auf dem gleichen Stand zu sein. Hilfreiche ältere Folge des Podcasts passend zum Thema: Den Wert des Produktes maximieren Wir hoffen, dass du einige neue Impulse zum Thema Business KPI mitnehmen konntest. Welche KPI nutzt du denn als Product Owner? Welche sind hilfreich für euch und führen zu guten Entscheidungen? Magst du darüber berichten? Wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Markus Andrezak & Oliver Winter im Gespräch mit Tim Es erscheint gar nicht so leicht, Produktstrategie in die Praxis zu bringen und deren erfolgreiches Wirken zu spüren. In der neuesten Folge des Produktwerker-Podcasts hatten wir das Vergnügen, mit Markus Andrezak, einem Experten in Sachen Produktstrategie, über dieses Thema zu sprechen. Als zweiten Gast hat sich Tim Klein, der Moderator dieser Folge, zudem Oliver Winter, unseren Experten für Strategie und Trainer unserer Produktstrategie-Trainings dazu geholt. Oliver ist diesmal also in der für ihn ungewöhnlichen Rolle als Gast dabei. Tim taucht mit Markus und Oliver tief in in die Frage ein, wie man das Thema Produktstrategie in der Praxis umsetzt, d.h. wie man Produktstrategie in die Praxis bringen und im oft chaotischen Alltag eines Product Owners zum Leben und damit zur Wirkung erwecken kann. Unklarheit als Zeichen fehlender Strategie Markus bringt es auf den Punkt: Wenn Unklarheiten in deinem Team oder deiner Organisation aufkommen, ist dies ein klares Zeichen dafür, dass eine Produktstrategie fehlt oder zumindest nicht klar definiert ist. Doch was tun, wenn du nicht gleich mit großen, überwältigenden strategischen Plänen beginnen möchtest? Hier kommt u.a. die „Challenge-Driven-Strategy“ ins Spiel, ein Konzept, das Markus am Ende des Gesprächs vorstellt. Schritt für Schritt zu mehr Klarheit Statt sofort die gesamte Strategie des Unternehmens auf den Prüfstand zu stellen, empfiehlt Experte Markus Andrezak, Schritt für Schritt vorzugehen. Er rät u.a. dazu, mit dem Produktteam regelmäßige Meetings einzuführen, in denen spezifische Probleme diskutiert und gelöst werden. Der Schlüssel dabei: Diese Treffen sollten immer ein konkretes Ziel haben und nicht in endloses Geplänkel abdriften. Durch diesen kontinuierlichen Prozess wird nicht nur die Zusammenarbeit im Team gestärkt, sondern es entsteht auch langsam, aber sicher eine strategische Ausrichtung des Produkts bzw. Services. Oliver ergänzt Markus’ Vorschlag, indem er betont, wie wichtig es ist, sich als Product Owner auf wenige, aber dafür wesentliche Themen zu konzentrieren. In vielen Teams geht der Fokus verloren, weil zu viele Baustellen gleichzeitig bearbeitet werden. Hierbei hilft es, sich auf die wirklich wichtigen Probleme zu konzentrieren und diese konsequent zu verfolgen. Fazit: Strategie ist kein Hexenwerk Die vielleicht wichtigste Erkenntnis aus dieser Folge? Strategiearbeit muss nicht immer als solche benannt oder formell angegangen werden. Häufig entsteht eine solide Strategie einfach durch die kontinuierliche, fokussierte Lösung von Problemen. Wenn du als Product Ownerin also das Gefühl hast, dass in deinem Produktteam oder deiner Organisation der strategische rote Faden fehlt, dann beginne einfach damit, die größten Unklarheiten aus dem Weg zu räumen – und beobachte, wie sich daraus nach und nach eine klare Produktstrategie entwickelt. Während des Gesprächs wird auch auf die alte, gute Folge mit Florian Meyer verwiesen: Wardley Mapping - Produktstrategie wie ein Schachspiel . Und im Intro natürlich auch auf die beiden super Folgen mit Markus Andrezak: Warum scheint die Product Owner Rolle so schwer zu sein? (Folge 3 und immer noch eine der meistgehörten Folgen!) Business- oder Nutzersicht: Welchen Blickwinkel sollte ein PO einnehmen? (neben Markus auch mit Sohrab Salimi - und durch die zwei Experten ausnahmsweise etwas länger als sonst) Weitere ältere Folgen können wir in diesem Kontext empfehlen: Eine Produktstrategie entwickeln Von der Produktstrategie zum Product Backlog (mit Roman Pichler) Eine Produktstrategie ohne Canvas erarbeiten (mit Tim Herbig) Wenn du weitere Fragen an Markus Andrezak hat oder mit ihm grundsätzlich in Kontakt kommen möchtest, erreichst du ihn am besten über sein LinkedIn-Profil . Was er ansonsten so treibt und vor allem, was hinter seiner überproduct Academy und dem neuen Angebot " The Strategy Collective " steckt, findest du auf seiner Website ueberproduct.de heraus. Wir hoffen, dass du einige neue Impulse zum Thema 'Produktstrategie in der Praxis' aus den Erfahrungen von Markus und Oliver ableiten konntest. Bist du selber vielleicht auch aktiv dabei, bei euch Produktstrategie in die Praxis zu bringen? Welche guten oder schlechten Erfahrungen hast du selber gemacht und magst darüber berichten? Wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Dominique & Oliver im Gespräch Die ersten Wochen in einer neuen Rolle als Product Owner können überwältigend sein. Als neuer PO steht man vor vielen Herausforderungen, gleichzeitig bietet sich aber unserer Meinung nach auch eine einmalige Chance: den Rahmen für die Produktentwicklung so zu setzen, dass man langfristig Spaß an der Arbeit hat und effektiv agieren kann. In dieser Folge diskutieren Dominique und Oliver vier Schritte, die sich als Orientierungshilfe für die ersten Wochen eignen: KONTEXT VERSTEHEN UND BEZIEHUNGEN AUFBAUEN Bevor man sich in operative Aufgaben stürzt, sollte der Fokus darauf liegen, den Kontext des Produkts und der Organisation zu erfassen. Es geht zu Beginn vor allem darum, relevante Stakeholder kennenzulernen, die Produktvision zu verstehen und die Erwartungen der Beteiligten zu klären. Diese Phase legt das Fundament für alle weiteren Schritte und hilft dabei, spätere Entscheidungen fundiert treffen zu können. RAHMEN FÜR DIE ENTWICKLUNG FESTLEGEN Sobald der Kontext in dem man sich als Product Owner bewegt klarer ist, gilt es, den Rahmen für die Produktentwicklung zu definieren. Dabei spielen sowohl das Aufsetzen eines gut strukturierten Backlogs als auch die Festlegung von Arbeitsweisen im Team eine zentrale Rolle. In diesem Schritt geht es vorangig darum, ein gemeinsames Verständnis zu schaffen, wie gearbeitet und welche Prioritäten gesetzt werden sollen. DELIVERY UND DISCOVERY VEREINEN Ein häufiger Stolperstein in der Produktentwicklung ist die Trennung von kontinuierlicher Lieferung (Product Delivery) und der Entdeckung neuer Optionen und Lösungen (Product Discovery). Beides sollte Hand in Hand gehen. Der Fokus liegt darauf, diese Denkweise im Team zu verankern und sicherzustellen, dass das Product Backlog sowohl kurzfristige Lieferziele als auch explorative Aufgaben berücksichtigt. ZIELE DEFINIEREN UND LANGFRISTIG AUSRICHTEN Darüber hinaus macht es Sinn, konkrete Outcome-Ziele zu definieren. Dominique und Oliver machen in der Episode klar, dass es hier nicht nur um das Setzen von Sprintzielen, sondern vor allem um übergeordnete Ziele wie Produk Goal, Quartalsziele oder KPIs geht. Diese geben allen Beteiligten eine klare Richtung und ermöglichen es, den Fortschritt regelmäßig zu reflektieren und anzupassen. Wichtig ist für die beiden hierbei, solche Ziele nicht zu früh zu formulieren. EIN LANGFRISTIGER ANSATZ Die beschriebenen vier Schritte sind nicht als starre Abfolge zu verstehen, sondern sollten regelmäßig reflektiert und angepasst werden. Auch nach mehreren Monaten lohnt es sich, immer wieder einen Schritt zurückzugehen und zu prüfen, ob der Rahmen noch passt oder ob der Fokus neu justiert werden muss. Am Ende bleibt es entscheidend, dass man als PO nicht nur operativ gefordert ist, sondern sich auch strategische Freiräume schafft, um das Produkt langfristig erfolgreich zu machen. Oliver und Dominique möchten mit diesen Impulsen Product Ownern für die ersten Wochen eine Idee an die Hand geben, wie ihr sinnvoll startet und euren Weg in der Produktentwicklung erfolgreich gestalten könnt.…
D
Die Produktwerker
Tobias Morauf im Gespräch mit Tim Guerilla Discovery – das ist ein vielleicht zunächst mal unbekannter oder ungewöhnlicher Begriff. Gemeint ist damit ein unterschwelliger und kontinuierlicher Weg, um Nutzereinblicke zu gewinnen, selbst wenn das Umfeld nicht ideal für tiefergehende Discovery-Prozesse ist. In dieser Episode ist Tobias Morauf, Senior Product Manager bei cosee, zu diesem Thema der Gesprächsgast von Tim. Er gibt spannende Einblicke in seine Art, für mehr Product Discovery zu sorgen - selbst wenn kein Budget bzw. kein expliziter Wille in seinem Produktkontext bzw. Projekt vorhanden ist, nach mehr Product Discovery zu streben. Wie das genau funktioniert und welche praktischen Tipps dabei helfen, beleuchten wir in dieser Folge unseres Podcasts. Unter Guerilla Discovery versteht Tobias ein Vorgehen, bei der Product Discovery nicht aufwendig und formal durchgeführt wird, sondern unterschwellig aber kontinuierlich in den Produktalltag integriert wird. Ziel ist es, trotz knapper Ressourcen und begrenztem Spielraum wertvolle Erkenntnisse zu sammeln. Ein zentraler Gedanke dabei: Discovery braucht oft weniger Zeit und Aufwand, als man denkt. Ein griffiges Beispiel, das Tobias Morauf aus seiner Praxis teilt, zeigt eindrucksvoll, wie dieser Ansatz funktioniert. In einem Projekt ging es um die Migration eines Systems, bei dem es eine klare Feature-Liste von der IT-Abteilung gab. Doch Tobias bemerkte schnell, dass es eine Diskrepanz zwischen den Anforderungen der IT und den tatsächlichen Bedürfnissen des Kundenservice gab. Statt einfach die bestehenden Anforderungen umzusetzen, entschied er sich, den Kundenservice direkt zu beobachten – ganz unauffällig und ohne großes Aufsehen. Durch diese einfache Maßnahme konnte Tobias feststellen, dass einige der ursprünglich geplanten Features überflüssig waren, während andere, wie die Möglichkeit, Kunden zu sperren oder zu anonymisieren, viel wichtiger waren. Diese Erkenntnisse führten nicht nur zu einer besseren Lösung, sondern halfen auch, unnötigen Aufwand zu vermeiden – ganz im Sinne von Jeff Pattons Prinzip: „Maximiere den Outcome, während du den Output minimierst.“ Um Guerilla Discovery erfolgreich in der Praxis umzusetzen, schlägt Tobias einen Ansatz in fünf Schritten vor: Stakeholder überzeugen: Oft gibt es Widerstände, wenn es um zusätzliche Discovery geht. Hier hilft es, mit gezielten Fragen und Annahmen zu arbeiten, statt sofort mit großen Konzepten oder umfangreichen Interviews zu starten. Nutzer verstehen: Der direkte Kontakt zum Nutzer ist essenziell. Wenn dieser nicht möglich ist, helfen kleine, kontinuierliche Beobachtungen und das Hinterfragen bestehender Annahmen. Im kleinen Rahmen experimentieren: Discovery kann auch in kleinen Schritten stattfinden. Es muss nicht immer der große Wurf sein. Auch kurze Beobachtungen oder Gespräche können wertvolle Einsichten liefern. Scope-Creep beachten: Jedes Projekt hat ein Budget, sei es finanziell oder zeitlich. Ein Teil dieses Budgets sollte bewusst für Discovery verwendet werden, da dies langfristig zu besseren Entscheidungen führt und letztlich Ressourcen spart. Den Scrum Master einbinden: Sollte es zu Widerständen im Team kommen, empfiehlt Tobias, den Scrum Master als Verbündeten zu gewinnen. Dieser kann oft helfen, Konflikte zu moderieren und den Fokus auf die Nutzerbedürfnisse zu lenken. Ein zentraler Punkt, den Tobias betont, ist der Mut, den Guerilla Discovery erfordert. Man muss halt aus der eigenen Komfortzone heraustreten und vielleicht auch mal anecken. Doch genau hier liegt der Schlüssel: Wer bereit ist, kleine Schritte zu gehen und immer wieder hinterfragt, kann selbst in einem schwierigen Umfeld wertvolle Erkenntnisse gewinnen. Fazit: Kleine Aktionen, große Wirkung Tobias’ Ansatz zeigt, dass Product Discovery nicht immer aufwendig oder formell sein muss. Durch gezielte, kleine Maßnahmen können auch in einem schwierigen Umfeld wichtige Erkenntnisse gewonnen werden. Dabei ist es entscheidend, den Nutzer in den Mittelpunkt zu stellen und kontinuierlich zu hinterfragen, ob die geplanten Lösungen wirklich die Probleme der Nutzer lösen – und das oft mit viel weniger Aufwand, als man denkt. Wer mehr darüber erfahren möchte, wie Tobias diesen Ansatz auf der „Crafting Products“ Konferenz vorgestellt hat, findet das Video des Vortrags auf der Website zu dieser Konferenz . Die nächste Ausgabe der "Crafting Products" Konferenz findet übrigens am 15. Mai 2025 statt – Save the Date! Auf diese älteren Episoden wird in dieser Folge verwiesen: Spielend Product Discovery und Delivery unter einen Hut bringen - mit Konstantin Diener Product Principles Impact Mapping - was zahlt wirklich auf unser Business Ziel ein? Und auf folgende Tools verweist Tobias: The Product Vision Board The GO Product Roadmap Wer weitere Fragen an Tobias hat oder mit ihm anderweitig in Kontakt treten möchte, erreicht ihn am Besten über LinkedIn. Hoffentlich kannst du aus diesem Erfahrungsbericht zum Guerilla Discovery ein paar Anregungen mitnehmen, wie du bei dir im Umfeld peu a peu zu mehr Discovery Arbeit kommst. Welche Erfahrungen hast Du selber gemacht, falls das Umfeld (noch) nicht so offen für Product Discovery ist? Wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Dr. Janna Lipenkova im Gespräch mit Tim Wir haben Dr. Janna Lipenkova mit dem Thema Produktentwicklung von AI Produkten zu Gast. Sie ist eine ausgewiesene und langjährige Expertin auf dem Feld von KI und NLP hat ihren Doktor in Computerlinguistik gemacht. Nachdem sie mehrere Jahre mit KI und NLP sowohl im akademischen als auch in der Industrie gearbeitet hat, hat sie inzwischen zwei eigene Unternehmen in dem Bereich gegründet, die jeweils künstliche Intelligenz nutzen, um modernste Business Intelligence bereitzustellen und helfen, intelligentere Entscheidungen, Strategien und Umsetzungen zu fördern. Zudem arbeitet sie derzeit als Autorin an einem Buch über die Entwicklung von Produkten mit KI, was bald erscheinen wird ("T he Art of AI Product Management - a guide for product managers ") Im Gespräch mit Tim gibt Janna zunächst ihr Definition von AI Systemen und stellt auf dieser Basis das von ihr entwickelte holistische mentale Modell vor, welches sie für die Produktentwicklung von AI Produkten empfiehlt. Sie folgt bei den drei grundsätzlichen Dimensionen des Produktmanagement (Technologie, UX, Business). Innerhalb dieser Dimensionen zeigt sie dann verschiedene Komponenten, auf, die man besonders bei der Produkte Entwicklung von AI Produkten beachten sollte. Im Bereich Technologie schlägt sie die Bereiche "Data" und "Intelligence" vor. Auf ihre Sicht zu UX von AI Produkten gehen wir in diesem Gespräch nicht so intensiv ein. Sie hat dies in einem tollen Talk beim ProductTank Cologne zuletzt sehr ausführlich getan. Hier der Link zum Video . In der Dimension Business schlägt sie die besondere Beachtung der beiden Komponenten "Value" und "Opportunity" vor und erläutert jeweils, was sie damit meint. Quellen aus diesem Gespräch: Artikel " Mental model of an AI system " Buch von Dr. Janna Lipenkova für Produktmanager: The Art of AI Product Management Wer mit Janna direkt in Kontakt treten möchte oder noch weitere Fragen an sie hat, erreicht sie am besten über ihr LinkedIn Profil . Mehr über ihr Unternehmen Anacode und ihr StartUp EQUINTEL findet ihr im Netz. Wir hoffen, dass Du einige neue Impulse aus den Erfahrungen von Dr. Janna Lipenkova ziehen konntest. Bist Du selber vielleicht schon im Rahmen der Produktentwicklung von AI Produkten aktiv? Was ist dabei für Dich anders? Welche Erfahrungen hast Du selber gemacht und magst darüber berichten? Wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Oliver & Tim im Gespräch Diesmal widmen wir uns dem Thema Künstliche Intelligenz (KI) beziehungsweise Artificial intelligence (AI) und beleuchten, wie diese die Rolle des Product Owners transformieren kann. Tim und Oliver diskutieren die Chancen und Herausforderungen, die sich durch den Einsatz von KI-Tools im Produktmanagement ergeben und fragen sich, wie AI als Wingman für Product Owner gut funktionieren kann. Künstliche Intelligenz ist mehr als nur ein Buzzword. Sie bietet Product Ownern die Möglichkeit, ihre Arbeitsweise zu revolutionieren. KI bietet nicht nur die Chance, Prozesse zu optimieren, sondern auch die Arbeitsweise in der Produktentwicklung grundlegend zu verändern. Dabei ist KI mehr als nur ChatGPT, auch wenn KI häufig mit Anwendungen wie ChatGPT gleichgesetzt wird. Machine Learning, Generative AI und spezialisierte Technologien wie Large Language Models (LLMs) sind nur einige Beispiele für die Bandbreite an Möglichkeiten. Tim erklärt, dass es wichtig ist, über ChatGPT hinauszublicken und andere KI-Anwendungen zu entdecken, die im Produktmanagement nützlich sein können. Im Gespräch werden zahlreiche Beispiele für den Einsatz von KI im Produktmanagement angesprochen: Stakeholder-Kommunikation: KI kann bei der Erstellung von Release Notes unterstützen und Storytelling durch die Generierung von Bildern und Videos bereichern. Produktstrategie und -vision: Mit KI-Tools lassen sich komplexe Dokumente wie der Amazon Six-Pager einfacher erstellen, indem die anfängliche Hürde des leeren Blattes überwunden wird. Wettbewerbsanalyse: KI kann helfen, Nutzerrezensionen des Wettbewerbs auszuwerten, um Differenzierungsvorteile oder neue Feature-Ideen zu entdecken. Datenanalyse: Mit KI können umfangreiche Datenmengen effizient analysiert werden, um wertvolle Insights zu gewinnen, z. B. durch die Auswertung von Hörstatistiken. Ein zentraler Punkt, den Tim hervorhebt, ist die Notwendigkeit, KI im Dialog zu nutzen. Es reicht nicht aus, nur gute Prompts für Generative AI zu schreiben. Vielmehr sollte KI wie ein Mitarbeiter behandelt werden, der Kontext und klare Anweisungen benötigt. AI als Wingman braucht diese Informationen, genauso wie andere Menschen. So können KI-Tools effektiver genutzt werden und wertvolle Unterstützung bieten. Beim Einsatz von KI-Tools müssen Datenschutz und ethische Überlegungen berücksichtigt werden. Product Owner sollten sich aktiv dafür einsetzen, KI-Tools im Unternehmen nutzen zu dürfen, dabei jedoch stets die datenschutzrechtlichen Rahmenbedingungen beachten müssen. Abschließend zeigt die bisherige Erfahrung, dass KI-Tools die Arbeit von Product Ownern bereichern können. Es geht darum, KI als unterstützenden Assistenten zu sehen, der hilft, Aufgaben effizienter zu gestalten, ohne die menschliche Rolle zu ersetzen. Wenn ihr mehr hören wollt, empfehlen wir euch anschließend die Folge " Wie No-Code Tools Produktteams helfen ". Ein paar nützliche Tipps zum Einsatz von KI im Sprint Review gab es in der Folge " Was macht ein gutes Sprint Review aus? ". Tim hatte auch bereits im Januar 2023 ein "Interview" mit ChatGPT zur PO Rolle geführt - diese Episode hieß " Was weiß künstliche Intelligenz schon über Produktentwicklung? " Die Newsletter, denen Tim folgt und somit (ganz subjektiv) empfehlen kann sind: STARTPLATZ AI Hub - KI Einblicke, Anwendungen, News und Exklusive Community-Events KI Tools Newsletter - Die neusten Tool und Entwicklungen aus der Welt der KI 🤓 Kurz, knapp und ohne viel blabla Wie sieht es bei euch aus? Nutzt ihr schon KI-Tools in eurer Arbeit als Product Owner, Product Manager und Product Leads? Wir sind gespannt von euren Erfahrungen zu hören. Wir freuen uns, wenn du deine Meinung zu KI und deine Einschätzung für KI in der Produktentwicklung mit uns in einem Kommentar des Blog-Artikels ( https://produktwerker.de/ai-als-wingman-fuer-product-owner/ ) teilst oder auf unserer Produktwerker LinkedIn-Seite ( https://www.linkedin.com/company/produktwerker) . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K…
D
Die Produktwerker
Oliver & Dominique im Gespräch Tim, Dominique und Oliver haben im Product Owner Podcast von Die Produktwerker schon in der einen oder anderen Folge über die Notwendigkeit einer Produkt Vision gesprochen. In dieser Episode geht es aber primär um die UX Vision bzw. das UX Vision Canvas, welches Dominique Winter in den letzten Jahren entwickelt und mit dem er in vielen Organisationen sehr erfolgreich gearbeitet hat. Das ist Grund genug, dass sich Oliver mit Dominique in der aktuellen Episode über das Thema ausführlich unterhalten haben. Die beiden starten in das Gespräch mit der Frage, warum es sich als Produktentwicklungsteam lohnen kann, auch eine UX Vision zu erarbeiten. Dominique teilt in der Diskussion seine reichhaltigen Erfahrungen, wie man an die Erstellung dieses Artefaktes herangehen sollte. Dabei kann das UX Vision Canvas bei vielen Fragestellungen und Perspektivwechsel gut unterstützen. Selbstverständlich ist das Befüllen der Felder des UX Vision Canvas kein Selbstzweck, sondern spannend wird es erst, wenn man in der täglichen Arbeit als Product Owner auch mit der abgestimmten UX Vision arbeitet. Auch hierzu teilt Dominique wieder viele Learnings aus der Praxis. Er hat einige Beispiele dabei, wie ich diese UX Vision nutzen kann und welche Herausforderungen dabei zu beachten sind. Wie jede Podcastfolge schließen die Beiden mit Tipps & Tricks ab. Download UX Vision Canavas - www.ux-vision.com…
Alexander Kylburg im Gespräch mit Tim Schon im Scrum Guide wird klar formuliert, dass Scrum Master in bestimmten Fragestellungen ihre Product Owner unterstützen sollen. Als ausgewiesenen Experten für die Scrum Master Rolle haben wir uns daher erneut Alexander Kylburg eingeladen. Er ist schon mindestens 15 Jahre in der agilen Szene und vor allem im Rheinland ein sehr engagiertes Mitglied der Agile Community. So hat er den Kölner Scrumtisch nahezu von Tag 1 begleitet und die regelmäßige Agile Cologne als bedeutende agile Konferenz zusammen mit anderen vor über 10 Jahren ins Leben gerufen. Tim bespricht mit Alexander zunächst mal, wie er die Verantwortlichkeit von Scrum Mastern versteht und wie sie selbst ihre Scrum Master weiterbilden. Natürlich auch, wie man als Scrum Master überhaupt in die Product Owner Themen reinkommen kann. Spannend ist seine Einschätzung, wie gut bzw. intensiv Scrum Master heutzutage ihre Product Owner unterstützen. Was muss ein Scrum Master dafür wissen, um eine wertvolle methodische Unterstützung bzw. entsprechendes Coaching leisten zu können? Aber de beiden kommen im Gespräch auch an den üblichen Problemen vorbei: Was ist, wenn sich der der Product Owner vielleicht gar nicht helfen lassen will bzw. faktisch der Scrum Master keinen entsprechenden Zugang zum Product Owner findet? Genauso kann sich das Problem auch andersrum darstellen: der Product Owner "zieht" den Scrum Master in inhaltliche und operative Arbeit hinein und missachtet dabei die eigentliche Rolle des Scrum Masters. Darüber hinaus gibt es in dieser Folge auch praktische Tipps, wie sich Scrum Master das entsprechende Wissen aneignen können und auf Augenhöhe bleiben können. Das von Alexander Kylburg mehrfach erwähnte " Agile Coaching Growth Wheel " ist in Toolbox (empfehlenswert!) von paragraph eins gut und detailliert beschrieben: paragraph1.de/toolbox/das-agile-coaching-growth-wheel Das Toleranz Modell und das am Ende erwähnte Kartenspiel " Toleranz Poker " könnt ihr dort ebenfalls finden. Auf folgende ältere Folgen wird im Laufe des Gesprächs verwiesen: Konflikte zwischen Scrum Master und Product Owner (mit Gast Alexander Kylburg Dein Freund der Scrum Master Wer mit Alexander Kylburg oder seiner Firma paragraph eins in Kontakt treten möchte, erreicht ihn am Besten auf seinem LinkedIn-Profil . Übrigens ist paragraph eins ein sehr geschätzter Kooperationspartner von uns. Wir hoffen, dass du mit dieser Folge wertvolle Ideen bekommen hast, wie du als Agile Coach oder Scrum Master deinen Product Owner unterstützen kannst. Welche Erfahrungen hast Du selber gemacht und magst darüber berichten? Wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Tim & Oliver im Gespräch Obwohl der Scrum Guide definiert, dass der Product Owner nur eine Person und kein Gremium sein soll, sehen wir in der Realität vieler Organisationen, dass die Product Ownership auf mehrere Personen aufgeteilt wird. Tim und Oliver analysieren in dieser Folge unterschiedliche Ausprägungen von Shared Product Ownership. Welche Herausforderungen entstehen, welche Vorteile hat ein solches Szenario und welche Nachteile muss ich in Kauf nehmen? In ihrem Gespräch kommen die beiden zu Schluss, dass es einige Kontexte gibt, in denen Shared Product Ownership sinnvoll sein kann, unabhängig davon was der Scrum Guide definiert. Natürlich schließen Oliver und Tim auch diese Folge wieder mit praktischen Tipps und Tricks ab, die Dir bei geteilter Verantwortung helfen können. **Links auf in der Folge erwähnte Quellen: **- Talk von Markus Andrezak Roman Pichlers Blogpost Podcastfolge: Ein Scrum Team, zwei POs - geht das?…
Jan Lensing im Gespräch mit Tim Wie läuft eigentlich ein richtig gutes Sprint Review? Mit unserem Gast Jan Lensing bespricht Tim dieses Thema nun auf Basis der konkreten Praxiserfahrungen von Jan. Jan ist Scrum Master bei der Firma comnovo - ein spannendes Industrieunternehmen mit Hardware- und Software-Produkten rund um die Entwicklung von Assistenzsystemen für die Intralogistik. Also sehr vereinfacht gesagt, damit man nicht von Gabelstaplern (in allen möglichen Dimensionen) überfahren wird. In diesem Kontext wird nach Scrum gearbeitet und über einen SAFe-Ansatz skaliert. Wir haben uns natürlich schon in früheren Folgen unseres Podcast um das Sprint Review gekümmert. Dennoch geben gerade die vielen Praxisbeispiele nochmal richtig wertvolle Impulse für dieses Scrum Event. Im Gespräch wird sowohl die gute Vorbereitung als auch die gelungene Durchführung eines Reviews besprochen. Zur Vorbereitung gilt natürlich schon die Frage, wann und wie lange man es durchführt sowie wie man die wichtigsten Stakeholder am besten einlädt. Bei der Verbesserung ihrer Sprint Reviews hat Jan Lensing tolle Ideen mitgebracht, die er mit seinen Teams bereits ausprobiert. Auf folgende ältere Folgen wir im Laufe des Gesprächs verwiesen: Als Product Owner im Sprint Review Sprint Review ohne Stakeholder Wer nimmt User Stories ab? Plattform Team Product Owner: eine besondere Herausforderung Hier noch der Link zum Video "Staplerfahrer Klaus" - ein echter Evergreen aus dem Jahr 2000 und damals vermutlich eines der ersten Videos, was richtig viral ging. Wer mit Jan Lensing in Kontakt treten möchte, um evtl. noch weitere Rückfragen zu klären, erreicht ihn am Besten auf seinem LinkedIn-Profil . Wir hoffen, dass du mit dieser Folge wertvolle Ideen bekommen hast, wie du als Scrum Master oder Product Owner ein gutes Sprint Review gestalten kannst. Welche Erfahrungen hast Du selber gemacht und magst darüber berichten? Wenn du deine Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Oliver & Dominique im Gespräch In dieser Folge sprechen Dominique und Oliver über Triggerpunkte gesprochen – sowohl unsere persönlichen als auch diejenigen, die wir in Produktorganisationen erleben. Diese Punkte können starke emotionale Reaktionen und Konflikte auslösen und sind oft tief in den Strukturen und Spannungen einer Organisation verwurzelt. In der Episode möchten wir die wichtigsten Erkenntnisse und einige Strategien vorstellen, wie man in Produktorganisationen diese Triggerpunkte erkennen und damit umgehen kann. Triggerpunkte sind Themen oder Ereignisse, die intensive emotionale Reaktionen hervorrufen. Sie können in vielen verschiedenen Kontexten auftreten, von gesellschaftlichen Themen wie Gender-Sternchen bis hin zu spezifischen organisatorischen Veränderungen. In der Arbeitswelt können Triggerpunkte zu Konflikten und Spannungen führen, die die Zusammenarbeit und Produktivität beeinträchtigen. Typische Triggerpunkte in Produktorganisationen Änderungen in der Produktstrategie Eine plötzliche Änderung der Produktstrategie, die nicht ausreichend kommuniziert oder begründet wird, kann bei den Betroffenen zu Unzufriedenheit und Widerstand führen. Produktverantwortliche müssen oft Entscheidungen umsetzen, die sie nicht nachvollziehen können, was das Gefühl der Ungerechtigkeit verstärken kann. Neue Tools und Prozesse Die Einführung neuer Tools oder Prozesse ohne Rücksprache mit dem Team kann starke negative Reaktionen auslösen. Dies gilt insbesondere, wenn die neuen Werkzeuge die bisherigen Arbeitsweisen erheblich verändern und zusätzliche Belastungen verursachen. Organisatorische Veränderungen Veränderungen in der Teamzusammensetzung oder organisatorische Umstrukturierungen können bestehende Spannungen verstärken. Wenn beliebte Teammitglieder versetzt oder entlassen werden, kann dies das Vertrauen und die Moral im Team beeinträchtigen. Mangelnde Kommunikation und Einbeziehung Eine unzureichende Kommunikation seitens der Führungsebene und das Gefühl, nicht in Entscheidungsprozesse einbezogen zu werden, können starke emotionale Reaktionen hervorrufen. Oft fühlen sich Mitarbeiter ungerecht behandelt oder nicht wertgeschätzt. Ursachen und Auslöser von Triggerpunkten Die Ursachen für Triggerpunkte liegen oft in tief verwurzelten Überzeugungen und Werten. Diese können durch mangelnde Transparenz, unzureichende Kommunikation oder das Fehlen von Ressourcen und Unterstützung verstärkt werden. Ein Gefühl der Ungerechtigkeit oder ungleiche Behandlung kann ebenfalls ein starker Auslöser sein. Strategien zum Umgang mit Triggerpunkten Offene und transparente Kommunikation fördern Eine klare und transparente Kommunikation ist entscheidend, um Triggerpunkte zu vermeiden oder zu entschärfen. Indem man die Gründe hinter Entscheidungen erläutert und die Betroffenen frühzeitig einbezieht, kann man Missverständnisse und Widerstände reduzieren. Vertrauen aufbauen Vertrauen ist die Grundlage für jede erfolgreiche Zusammenarbeit. Führungskräfte sollten durch ihr Verhalten Vertrauen schaffen, indem sie sich öffnen, Schwächen zeigen und die Meinungen und Bedürfnisse der Mitarbeiter ernst nehmen. Ressourcen bereitstellen Um mit neuen Herausforderungen umzugehen, benötigen Teams ausreichende Ressourcen und Unterstützung. Schulungen und Weiterbildungen können helfen, die Kompetenzen zu erweitern und die Arbeitsbelastung zu bewältigen. Kulturelle Veränderungen anstoßen Eine positive Unternehmenskultur, die auf Vertrauen, Offenheit und Zusammenarbeit basiert, kann langfristig dazu beitragen, Triggerpunkte zu minimieren. Führungskräfte sollten diese Kultur vorleben und kontinuierlich fördern. Sprache bewusst wählen Die Wahl der Worte kann einen großen Unterschied machen. Anstatt Begriffe zu verwenden, die negative Assoziationen hervorrufen, sollte man neutralere oder positivere Formulierungen wählen, um Widerstände zu vermeiden. Abschließend halten Dominique und Oliver fest, dass Triggerpunkte ein unvermeidlicher Teil des Arbeitslebens sind, insbesondere in dynamischen und veränderungsbereiten Produktorganisationen. Indem wir uns ihrer bewusst werden und Strategien entwickeln, um mit ihnen umzugehen, können wir nicht nur Konflikte reduzieren, sondern auch eine produktivere und zufriedenere Arbeitsumgebung schaffen. Lassen Sie uns offen und transparent kommunizieren, Vertrauen aufbauen und die notwendigen Ressourcen bereitstellen, um gemeinsam erfolgreich zu sein. Quelle und Verweise: Triggerpunkte - Konsens und Konflikt in der Gegenwartsgesellschaft | Warum Gendersternchen und Lastenfahrräder so viele Menschen triggern Von Steffen Mau, Thomas Lux, Linus Westheuser - 2023…
Oliver & Tim im Gespräch Wir Produktwerker werden immer häufiger als Impulsgeber für interne Veranstaltungen angefragt. Und so gerne wir solche Mandate auch annehmen, fragen wir uns, wo denn die ganzen Product Owner bei den vielen Konferenzen, Meetups oder Online-Webinaren eigentlich sind. Daher appellieren Tim und Oliver in der aktuellen Podcastfolge an alle POs: Geht raus aus eurem Gebäude, holt euch Hilfe und seid keine Einzelkämpfer. Zu Beginn der Episode teilen die Beiden ihre persönlichen Beobachtungen von Konferenzen, aber auch die Beteiligung an aktuellen Diskussionen beispielsweise auf LinkedIn oder X. Tim und Oliver kommen zu dem Schluss, dass meist mehr Scrum Master & Agile Coaches solche Angeboten annehmen als Product Owner, obwohl es theoretisch gleich viele von ihnen geben müsste. Was sind mögliche Gründe, dass Product Owner nicht so oft derartige Angebote wahrnehmen. Warum suchen sie wenig Hilfe von anderen Product Ownern? Ist der eigenen Workload zu groß, die Energie zu gering oder ist es der Glaube, dass der Kontext, in denen andere POs arbeiten zu unterschiedlich ist als dass man selber etwas lernen kann? Auf alle Fälle entstehen so einige Probleme, die Tim und Oliver auch diskutieren. Und wie in jeder Podcastfolge haben die Beiden aber auch zahlreiche Ideen mitgebracht, falls man an der eigenen Situation etwas verändern möchte. Wir immer schließt die Episode mit einigen Tipps und Tricks ab, die Du sofort umsetzen kannst.…
Timothy Krechel im Gespräch mit Tim Was sind Pirate Metrics? Das auch als das AARRR-Modell bekannte Set von Metriken hat vor allem im Bereich des Growth Marketing starke Verbreitung und Bekanntheit. Unser Gast Timothy Krechel ist Head of Digital Product Consulting bei Qvest Digital und nutzt die Pirate Metrics auch gerne in der Arbeit von Produktmanagern. Zunächst ergründen Tim und Timothy im Gespräch, was das Akronym "AARRR" bedeutet und woher der Begriff "Pirate Metrics" kommt. Ja - tatsächlich ist hier die Analogie zum furchteinflößenden Ruf von Piraten der profane Grund. Die Abkürzung AARRR steht hingegen für die fünf wichtigsten Funnel-Schritte, auf die sich jedes Unternehmen konzentrieren sollte: „Acquisition“ (Akquisition), „Activation“ (Aktivierung), „Revenue“ (Umsatz), „Retention“ (Kundentreue) und „Referral“ (Empfehlungen). Das Modell hilft, die Customer Journey und die bevorzugten Kanäle der Nutzer besser zu verstehen und in (strategischen) Diskussionen entsprechende Klarheit herzustellen. Außerdem ermöglichen diese sogenannten "Pirate Metrics", umsetzbare Ziele je Funnel-Step festzulegen. Timothy Krechel erklärt dann jeden Schritt des AARRR-Modells im Detail und zusammen mit Tim wird das Verständnis anhand von Beispielen geschärft. Natürlich gibt es noch andere Funnel-Ansätze als die Pirate Metrics. Aber gerade für transaktionsbasierte Geschäftsmodelle ist eine solche Funnel-Darstellung hilfreich. Tim zeigt auch Beispiele aus dem Produktportfolio der Produktwerker zu den einzelnen Steps auf. Spannend wird dann die Frage, wie das AARRR-Modell konkret zu nutzen ist und vor allem, wie es mir als Product Owner helfen kann. Hier gibt der Gast Timothy Krechel wertvolle Impulse, wie die Pirate Metrics in den Alltag als Product Owner integriert werden können. Abschließend zeigt Timothy aber auch die Schwächen der Pirate Metrics auf, um ein rundes Bild zu zeichnen. Passende Podcast-Folgen rund um das Thema Customer Journey: Mit Customer Journey Maps arbeiten Customer Journey Management im Konzern - ein Erfahrungsbericht Wenn ihr weitere Fragen an Timothy habt oder mit ihm Kontakt aufnehmen möchtet, vernetzt euch am besten via LinkedIn mit ihm oder schreibt an hello@timothy.de. Weiteren wertvollen Content von und mit Timothy Krechel gibt es in den Product Lunches von Qvest Digital. Kanntest du die Pirate Metrics? Und nutzt ihr sie auch in der Praxis bei euch?Wie bindest du dann das AARRR-Modell in deine Arbeit als Product Owner ein? Wenn du deine Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Dominique & Tim im Gespräch Es ist Sommer und der Product Owner macht Urlaub - echt jetzt? Geht das überhaupt? Immerhin ist die Rolle ja ohne dedizierte Stellvertretung in Scrum ausgelegt. Die Frage stellen sich jetzt zu Beginn der Urlaubszeit im Sommer sicherlich wieder einige Teams und Product Owner oft auch selbst. Dominique und Tim diskutieren darüber und sind sich grundsätzlich einig: dass ein Product Owner Urlaub macht ist unerlässlich, um sich zu erholen und wieder Kraft zu tanken. Die Vorstellung, dass ein Product Owner unersetzlich seien, kann problematisch sein. Mit den richtigen Maßnahmen lassen sich Probleme während der Abwesenheit jedoch minimieren. Denn ohne gute Vorbereitung und eine vernünftige Übergabe kann es sonst wirklich problematisch für den Erfolg der Produktentwicklung werden. Eine gute Vorbereitung ist besonders entscheidend. Wichtig ist, dass alle relevanten Prozesse und Entscheidungen dokumentiert sind. Das Team sollte frühzeitig über den geplanten Urlaub informiert und Aufgaben sowie Verantwortlichkeiten klar delegiert werden. Ein gründlicher Wissenstransfer sorgt dafür, dass die Vertretung vom Product Owner Zugriff auf alle notwendigen Dokumente und Ressourcen hat. Zudem sollte das Product Backlog gepflegt und Sprintziele klar definiert werden, um Transparenz über den Status der Produktentwicklung zu gewährleisten. Während der Abwesenheit des POs muss die Kommunikation mit dem Team und den Stakeholdern klar geregelt sein. Es sollte klar sein, wer die Ansprechpartnerin ist und wie Eskalationswege aussehen. Die Erreichbarkeit des POs im Notfall sollte ebenfalls geklärt sein. Manchmal kann das Sinn machen. Nach dem Urlaub ist es wichtig, die Aufgaben und Verantwortlichkeiten schrittweise wieder zu übernehmen und sich über den aktuellen Stand zu informieren. Die während der Abwesenheit getroffenen Entscheidungen sollten explizit besprochen werden. In der Retrospektive kann besprochen werden, wie sich die Abwesenheit auf das Team ausgewirkt hat und welche Verbesserungen für die Zukunft vorgenommen werden können. Tim und Dominique empfehlen, sich auch auf unvorhergesehene Abwesenheiten vorzubereiten und nach dem Urlaub nicht sofort wieder zu 100% in den Arbeitsalltag einzusteigen. Eine gut vorbereitete Abwesenheit ist nicht nur möglich, sondern auch wichtig für die nachhaltige Entwicklung des Produkts und die eigene Erholung. In der Episode wird auch auf diese älteren Podcast-Folgen Bezug genommen: POEM - Product Ownership Evolution Model Dein Freund der Scrum Master Wie geht ihr mit dem Thema des Urlaubs vom Product Owner um? Vielleicht hast du ja auch Tipps für andere Product Owner, wie ihr das so löst und welche Erfahrungen ihr da schon gemacht habt? Wenn du deine Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Thorsten Jonas im Gespräch mit Dominique In dieser Folge unseres Podcasts dreht sich alles um das wichtige Thema der Nachhaltigkeit in der digitalen Produktentwicklung. Unser Gast, Thorsten Jonas, Experte für digitale Nachhaltigkeit und Gründer des Sustainable UX Network, teilt seine umfangreiche Erfahrung und wertvolle Einblicke mit uns. Thorsten erklärt, was digitale Nachhaltigkeit wirklich bedeutet, und zeigt auf, wie Unternehmen durch gezielte Maßnahmen ihre digitalen Produkte umweltfreundlicher gestalten können. Er spricht über die Herausforderungen, denen Organisationen begegnen, wenn sie nachhaltige Praktiken einführen, und wie diese überwunden werden können. Wir erfahren, welche Tools und Methoden Thorsten und sein Team im Sustainable UX Network nutzen, um Nachhaltigkeit in den gesamten Produktdesignprozess zu integrieren. Thorsten gibt zudem praktische Tipps, wie man mit einfachen Schritten beginnen kann, digitale Produkte nachhaltiger zu machen. Ein besonderes Highlight der Folge sind Thorstens konkrete Handlungsempfehlungen für sofort umsetzbare Maßnahmen, um den CO2-Fußabdruck digitaler Produkte zu reduzieren und langfristig nachhaltigere Prozesse zu etablieren. Hört rein und lasst euch inspirieren, wie ihr eure digitale Produktentwicklung nachhaltig gestalten könnt! Hier findet ihr alle erwähnten Links und Ressourcen: Website Carbon Calculator v3 The 17 Goals - Sustainable Development Web Sustainability Guidelines 1.0 Needs to Consequences Mapping Sustainable User Journey Mapping…
Tim & Oliver im Gespräch Als Product Owner treffen wir ständig Entscheidungen. Priorisierung des Product Backlogs, Festlegen eines Sprintziels, das nächste Ziel auf der Product Roadmap oder die vielen anderen, kleinen Dinge im Alltag. Warum das Entscheiden eher einem Pokerspiel als einem Schachspiel gleicht und Product Owner wie Pokerspieler denken sollten, darüber sprechen Tim und Oliver in dieser Episode. Die zwei Faktoren, die das Ergebnis einer Entscheidung entscheiden, sind die Qualität des Entscheidungsprozesses und Glück. Diese These formuliert Annie Duke, professionelle amerikanische Pokerspieler in ihrem Buch “Thinking in Bets”. Dieses in Wetten denken ist ein gutes Gedankenmodell für Product Owner. Denn bei jeder Entscheidung existiert ein gewisses Maß an Unsicherheit. Wichtig ist zu wissen, wie hoch meine Gewinnchancen sind und was ich einsetzen muss, wenn ich diese Wette eingehe. So kann ich wie im Poker den Anteil guter Wetten erhöhen und erfolgreicher sein. Der zweite, auch im Produktkontext hilfreiche Gedanke ist, nicht vom Ergebnis einer Entscheidung auf die Qualität der Entscheidung zu schließen. Dies folgt aus der Komponente Glück, denn selbst wenn ich zu 95% sicher bin, können die 5% doch eintreten. Wenn ich als Product Owner wie ein Pokerspieler mich nicht zu sehr von den Ergebnissen beeinflussen lasse, dann werde ich beispielsweise selbstbewusster auftreten und meine Entscheidung nachträglich den Stakeholdern begründen können.…
Ulf Schubert im Gespräch mit Dominique Wie entwickelt man eigentlich Produkte, die Kunden wirklich lieben? Diese Herausforderung kennen viele von uns. Unser Gesprächspartner ist diesmal Ulf Schubert, ein erfahrener UX-Experte, der uns wertvolle Einblicke und praktische Tipps dazu geben kann. Ulf weißt direkt am Anfangdarauf hin, dass es nicht genügt, ein Produkt nur optisch ansprechend zu gestalten. Der Schlüssel liegt darin, die verschiedenen Anforderungen und Erwartungen der Nutzenden zu verstehen und auszubalancieren. Es geht darum, ein holistisches Design zu schaffen, das sowohl visuell als auch interaktiv ansprechend ist und die Bedürfnisse der Nutzer erfüllt. Es ist außerdem schwer, sich allein durch technischen Fortschritt zu differenzieren. Stattdessen sollten Unternehmen schnell die Bedürfnisse ihrer Kund:innen erkennen und diese besser als die Konkurrenz erfüllen. Der Fokus sollte darauf liegen, die Erwartungen der Kund:innen zu übertreffen, um Begeisterung zu erzeugen und dadurch positive Mundpropaganda zu fördern. Ein zentraler Punkt in dem Gespräch war die Methodik. Ulf betonte, dass es nicht die Methode an sich ist, die entscheidend ist, sondern wie flexibel und spielerisch man mit ihr umgeht. Er hob das Konzept der Product Discovery hervor, bei dem vier Fragen im Mittelpunkt stehen: Welche Bedürfnisse gibt es? Wie müssen wir sie erfüllen? Können wir das technisch umsetzen? Und erreicht das unsere geschäftlichen Ziele? Für erfolgreiches Produktmanagement ist es essentiell, kontinuierlich von den Kunden zu lernen und sich anzupassen. Dies erfordert sowohl eine hohe Kundenkompetenz als auch einen datenbasierten Ansatz. Teams sollten regelmäßig Feedback einholen und Nutzungsdaten analysieren, um schnell auf Veränderungen reagieren zu können. Empathie spielt dabei eine zentrale Rolle. Ulf betonte, wie wichtig es ist, dass Teams die Bedürfnisse und Erwartungen der Nutzer verstehen und sich in deren Lage versetzen können. Dies kann durch direkte Interaktion mit den Kunden, etwa durch Besuche vor Ort oder Teilnahme an Nutzertests, erreicht werden. Zum Abschluss des Gesprächs gab Ulf zwei wesentliche Tipps: Nehmt euch Zeit, Empathie für die Kund:innen zu entwickeln. Hört zu und beobachtet sie genau, um deren Bedürfnisse und Erwartungen zu verstehen. Erweitert eure Perspektive und betrachtet das Produktdesign ganzheitlich. Eine gute Lösung ist immer ein Zusammenspiel verschiedener Aspekte – technischer, fachlicher und gestalterischer Natur. Durch diese Ansätze können Produkte entwickelt werden, die nicht nur funktional und ansprechend sind, sondern die Kund:innen wirklich lieben. Ein Produkt, das Bedürfnisse erfüllt und Erwartungen übertrifft, schafft Begeisterung und langfristige Zufriedenheit.…
D
Die Produktwerker
Oliver & Tim im Gespräch Zack! Gerade wurde dir mitgeteilt, dass du nun plötzlich Product Owner sein sollst. Puh, was heißt das und was wird ab jetzt von mir erwartet? Diese Situation kommt gar nicht so selten vor - nach unserer Beobachtung vor allem in größeren Unternehmen. Oliver und Tim beleuchten die verschiedenen Kontexte und Situationen in denen dies geschehen kann und erklären damit ein Stück weit, wie es dazu kommt. Ihre Beobachtungen basieren auf ihrer langjährigen Erfahrungen in agilen Transformationen sowie auch aus ihrer Mentoring- und Trainingspraxis bei der Begleitung von (neuen) Product Ownerinnen und Produktorganisationen im Umbruch. Vor allem liefern die beiden aber Empfehlungen und Tipps, wie man selbst mit so einer Herausforderung umgehen kann. Wie kann ich diese neue Rolle dabei vielleicht sogar aktiv gestalten? Vieles hängt dabei daran, mehr Rollenklarheit herzustellen (Stichwort: Erwartungsmanagement). Genauso wichtig ist aber auch, die mögliche eigene Unsicherheit offen anzusprechen und sich bei "Umlernen" von seinem direkten Teamumfeld helfen zu lassen. Auf diese Podcast-Folgen wird im Gespräch verwiesen: Welche Aufgaben gehören zur Product Owner Rolle? Stellenausschreibungen für Product Owner - WTF? Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner Plattform Team Product Owner: eine besondere Herausforderung Vom Projektleiter oder Teamleiter zum Product Owner POEM - Product Ownership Evolution Model Sei dein eigenes Produkt! – Weiterentwicklung für Product Owner Nutze Story Mapping, um mit Stakeholdern über Outcome zu sprechen Weitere empfohlene Quellen zur Herausforderung plötzlich Product Owner zu sein: Video " Story-Mapping " im Produktwerker-YouTube-Kanal Matt LeMay: Product Management in Practice (zu den "CORE Skills") Beispielhafter Artikel zur “ How to Work with Me ” Idee mit weiterführenden Links und Templates Kennst du die Situation, plötzlich Product Owner zu sein? Gab's oder gibt es das in deinem Umfeld vielleicht auch? Wie hast du das empfunden oder was hast du beobachtet? Vielleicht hast du ja auch Tipps für andere Product Owner? Wenn du deine Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
D
Die Produktwerker
Dominique & Oliver im Gespräch In dieser Podcast-Episode tauchen Dominique und Oliver tief in das Konzept des "The Decision Stack" ein und diskutieren, welche Erkenntnisse ein Product Owner aus dem mentalen Model von Martin Eriksson ziehen kann. Das Thema, was die meisten Product Owner, mit denen wir als Produktwerker arbeiten dürfen, tagtäglich beschäftigt, ist die Priorisierung der Anforderungen und die Sortierung der Product Backlog Items. Unserer Erfahrung nach handelt es sich bei dieser Herausforderungen gar nicht um das eigentliche Problem sondern ist lediglich das Symptom für das Fehlen einer angestimmten, logischen Vorgehensweise auf visionärer, strategischer und taktischer Ebene. Oliver und Dominique teilen daher zu Begin der Folge unterschiedliche Situationen aus ihrer eigenen Praxis. Für die Lösung dieser Herausforderungen bietet der Decision Stack ein strukturiertes aber dennoch einfaches mentales Model an, um mit komplexen Entscheidungen auf allen Flughöhen umgehen zu können. Oliver erklärt die einzelnen Elemente, Product Vision, Product Strategy, Objectives, Opportunities und Tasks und wie diese zusammenhängen. Im nächsten Schritt konkretisieren die beiden das Model für den Kontext eines Produkt Owners. Dominique und Oliver überlegen, wann und wie wir als Product Owner den Decision Stack effektiv in der täglichen Arbeit einsetzen können, um zielgerichteter agile unser Produkt weiterzuentwickeln. Wie immer schließt die Folge mit praktischen Tipps und Tricks ab. Martin Eriksson hat auf seiner Webseite eine ganze Reihe von Informationen, Slides und Videos zum Decision Stack geteilt. Der Gründer der Mind the Product Bewegung kündigt auch ein eigens Buch zu dem Thema an. Wir wünschen Dir wie immer vielen neue Impulse für Deine eigene Arbeit als Product Owner.…
Dominique & Tim im Gespräch Immer häufiger trifft man auf Product Owner von einem Plattform Team. Schnell kommen dann die Fragen auf, ob und wie die Ideen eines klassischen Scrum Product Owners anwendbar sind. Was ist das Produkt? Was sind in diesem Fall die Kunden bzw. besser gesagt die Nutzer? Ganz offensichtlich ergeben sich aus solchen Rahmenbedingungen eine Reihe von ganz speziellen Herausforderungen. Daher nehmen sich Dominique Winter und Tim Klein in dieser Folge des Themas an. Entsprechend klären sich zunächst mal die Frage, was genau hinter dem Begriff des Plattform Teams steckt und wie es sich von den Experience Teams abgrenzt. Unter den besonderen Herausforderungen heben sie hervor, sich nicht in die Ecke eines internen Dienstleisters drängen zu lassen. Auch wenn man als ein solcher Product Owner keinen externen Marktzugang hat, ist der Aufbau eines echten Problemverständnisses der (internen) Nutzer aus den sog. Experience Teams sehr wichtig. Auch Stakeholder Management bekommt als Product Owner eines Plattform Teams eine besondere Bedeutung. In der Regel hat man ja mehrere andere Teams, dem eine solche Plattform zur Nutzung bereitgestellt wird. Schnell können dadurch unterschiedliche oder auch widersprüchliche Anforderungen herangetragen werden. Die eigene Plattform muss aber gemäß der eigenen Produktvision in eine geplante Richtung entwickelt werden. Die Gefahr, es jedem internen Stakeholder Recht zu machen und damit mit der Plattform zum Spielball der Kräfte zu werden, ist ansonsten sehr hoch. Es geht also letztlich darum, den Wert der eigenen Plattform als Lösung für die Probleme der Experience Teams im Blick zu behalten und die Plattform Lösung als gestaltende Product Ownerin zu führen. In dieser Folge wird auf diese Quellen referenziert: Podcast-Folge: Vom Entwickler zum Product Owner Manuel Pais und Matthew Skelton: " Team Topologies: Organizing Business and Technology Teams for Fast Flow " Marty Cagan: " EMPOWERED " Bist du evtl. selber auch Product Owner in einem Plattform Team oder arbeitest du in bzw. mit einer solchen Teamkonstellation? Welche Herausforderungen erlebst du ähnlich, welche weiteren siehst du noch? Und hast du ergänzende Tipps für die Situation auf Basis deiner eigenen Erfahrung? Wenn du deine Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Christina Lange im Gespräch mit Tim In dieser Podcast-Folge widmen wir uns der Herausforderung, OKR in der Praxis sinnvoll einzusetzen. Tim hat dafür die Expertin und Autorin Christina Lange zu Gast. Sie ist freiberuflich OKR Coach und hauptberuflich Head of Agile und Lead Digital Academy bei der METRO.digital. Christina erlebt also seit vielen Jahren OKR in der Praxis und kennt daher auch die praktischen Probleme und Grenzen bei Nutzung und Einführung von Objectives & Key Results (OKR). Zunächst definiert sie, was OKR überhaupt sind und wie sie funktionieren. Wir diskutieren, in welchen Situationen OKR besonders effektiv eingesetzt werden können und welche Vorteile sie im Vergleich zu anderen Zielsetzungsmethoden bieten. Gleichzeitig beleuchten wir auch die Grenzen von OKR und wann sie möglicherweise nicht die beste Wahl sind. Ein wichtiger Aspekt ist die Einführung von OKR in Unternehmen. Hier teilt Christina Lange ihre Erfahrungen und Tipps, um einen erfolgreichen Start mit OKR zu gewährleisten, inkl. der Strategien zur Bewältigung von Problemen mit bzw. den "Missbrauch" von OKR. Besonders interessant ist für unseren Podcast natürlich die Rolle von Product Ownern im OKR Kontext. Tim bespricht mit Christina, wie Product Owner OKR nutzen können, um ihre Produktstrategie zu unterstützen, und welche Herausforderungen sich dabei ergeben können. Des Weiteren wird beleuchtet, wie OKR mit Scrum zusammenpassen und wie sie sich grundsätzlich in agile Arbeitsweisen integrieren lassen. Abschließend betrachten wir die Anwendung von OKR im Kontext von Product Discovery und wie sie die Produktentwicklung und Innovationsprozesse unterstützen können. Erwähnte Podcast-Episoden: Product Coaching - Gast: Annette Greil Was die Einführung von OKR für Product Owner bedeutet - Gast: Stefanie Götten Erwähnte und empfohlene Bücher & Quellen: Christina Lange: OKR in der Praxis: Objectives & Key Results – Beispiele, Hacks, Erfahrungen Ben Lamorti: The OKRs Field Book: A Step-by-Step Guide for Objectives and Key Results Coaches John Doerr: Measure What Matters - How Google, Bono, and the Gates Foundation Rock the World with OKRs Christina Wodtke: Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results Bart Den Haak: Moving the Needle With Lean OKRs: Setting Objectives and Key Results to Reach Your Most Ambitious Goal Blog von Filipe Castro: OutcomeEdge.com Falls du weitere Fragen hast und gerne Kontakt zu Christina Lange aufnehmen möchtest, dann verbinde dich mit ihr über ihr LinkedIn-Profil . Sie freut sich über deine Nachricht. Weiterhin möchten wir euch den Blog von Christina Lange ans Herz legen: pragmaticchange.com Welche Erfahrungen habt ihr mit der Einführung von Objectives & Key Results gemacht? Wie fühlen sind OKR in der Praxis bei euch an und wie arbeitest du als Product Owner mit den OKR? Kannst du sie in deine Arbeit einbinden? Wir Produktwerker freuen uns, wenn mit uns dein Feedback zu dieser Folge teilst. Konntest du den einen oder anderen Impulse mitnehmen? Wenn du deine Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Tim und Dominique im Gespräch Eine der häufig gestellten Fragen ist, wer eigentlich festlegt, wer zum Product Owner ernannt wird. Da uns diese Frage oft gestellt wird, diskutieren Tim und Dominique in dieser Folge über ihre Erfahrungen. Zunächst werfen wir einen Blick in den Scrum Guide, müssen jedoch feststellen, dass dort nicht viel dazu steht. Trotzdem haben sich in der Praxis verschiedene Möglichkeiten entwickelt, wie Organisationen die Rolle des Product Owners vergeben. Eine Möglichkeit ist beispielsweise, jemanden direkt aus dem Team zu ernennen. Alternativ wird diese Entscheidung oft durch das Management oder die Stakeholder getroffen. Hierbei gibt es verschiedene Ansätze, insbesondere in Bezug darauf, wie stark das Team in den Auswahlprozess einbezogen wird. In Bezug auf die Rolle des Scrum Masters stellt sich dann die Frage, wie diese Person bei der Suche nach der besten Besetzung für die Position des Product Owners unterstützen kann. Dann gehen Tim und Dominique ins Detail und besprechen die Auswahlprozesse, die sie bereits erlebt haben. Diese reichen von umfassenden und simultanen Einführungen, über einen Rekrutierungsprozess mit kollegialer Unterstützung, bis hin zu einem internen Assessment. Manchmal wird die Auswahl auch durch externen Druck beeinflusst, wenn beispielsweise ein Fachbereich gezwungen wird, einen Product Owner zu stellen. Dies kann dazu führen, dass man als Product Owner plötzlich ein zweites Produkt mit einem zweiten Produktteam betreuen muss. Obwohl dies nicht ideal ist, bietet es zumindest die Möglichkeit, dass das Produktteam mehr Verantwortung übernehmen kann. Erwähnte Podcastfolgen Und plötzlich war ich dann Product Owner - Ein Erfahrungsbericht ( https://produktwerker.de/und-ploetzlich-war-ich-dann-product-owner-ein-erfahrungsbericht/ ) Seine Stakeholder kennen und richtig analysieren ( https://produktwerker.de/stakeholder-analysieren/ ) POEM - Product Ownership Evolution Model ( https://produktwerker.de/poem-product-ownership-evolution-model/ ) Wie bist du in die Product Owner Rolle gekommen? Wer legt bei euch fest, wer Product Owner wird oder wann man es auch nicht mehr ist? Wie läuft das bei euch? Lass uns gerne einen Kommentar auf unserer Webseite ( www.produktwerker.de ) oder auf LinkedIn ( https://www.linkedin.com/company/produktwerker ) da.…
Nadja Deuerlein im Gespräch mit Oliver Yoga für Product Owner: Nadja Deuerlein ist Product Ownerin und Yoga-Lehrerin. Während ihrer persönlichen Lernreise von einer Softwareentwicklerin zur PO als auch zu einer ausgebildeten Yoga-Lehrerin hat sie interessante Parallelen zwischen agiler Produktentwicklung und Yoga beobachtet. Und genau über diese Erkenntnisse spricht Nadja in dieser Episode mit Oliver. Zu Beginn der Folge erklärt Nadja, dass Yoga mehr ist als die bekannten Asanas - die Körperstellungen bzw. Körperlichen Übungen - und Dyhana - die Meditation. Im Yoga-Sutra werden unter anderem auch die Yamas und die Niyamas beschrieben. Bei den Yamas handelt es ich um einen Verhaltenskodex gegenüber der eigenen Umwelt. Die Niyamas umfassen dagegen das Verhalten zu sich selbst. Vereinfacht gesagt werden hier Normen und Regeln zusammengefasst, die für das zwischenmenschliche Handeln Relevanz haben. Oliver diskutiert mit Nadja, welche Schnittmenge es zwischen diesen „10 Geboten“ des Yogas und den Herausforderungen als Produkt Owner gibt. Nadja erklärt alle 5 Yamas und 5 Niyamas und überträgt diese auf ihre Aufgaben als Product Ownerin. Ihr Erfahrungsbericht gibt eine ganze Reihe wertvoller Tipps und Trick für die Weiterentwicklung der eigenen Persönlichkeit. Die beiden ziehen darüber hinaus Vergleiche zum Agilen Manifest und dessen Ziel. Wie immer endet die Episode mit praktischen Tipps und Tricks für deine eigene Product Owner Tätigkeit.…
Oliver & Dominique im Gespräch Die Herausforderung als Product Owner lässt einen oft unter dem Druck stehen, alles gleichzeitig zu managen. Wir stellen die brennende Frage: Was mache ich, wenn ich als Product Owner keine Zeit für alles, was ich tun möchte, muss oder sollte, habe? Das Empfinden, keine Zeit zu haben, entsteht oft erst einmal dadurch, dass viel Arbeit liegen bleibt oder man zumindest das Gefühl hat, sich nicht mit den wichtigen Dingen beschäftigen zu können. Man ist getrieben und fühlt sich oft fremdgesteuert. Das Erste, was man dann machen sollte, ist, die eigene Zeit und vor allem den Einsatz der eigenen Zeit zu erheben. Durch das Mittracken der eigenen Zeit und das kritische Analysieren der Ergebnisse (Inspect & Adapt) bieten sich Einblicke, wie man effektiver arbeiten kann. Die wichtigste Methode dabei ist, mehr Fokus herzustellen. Wir diskutieren bewährte Methoden, um den Arbeitsalltag besser zu strukturieren. Von der Anlage eines Backlogs für eigene Aufgaben über die Pomodoro-Technik bis hin zum Einsatz eines Bullet Journals – diese Techniken helfen dabei, den Fokus zu schärfen und produktiver zu sein. Oft ist der Fokus aber gar nicht so schnell herstellbar. Daher haben wir Tipps besprochen, wie man sofort mehr Zeit gewinnen kann. Wir erörtern, wie das Ausschalten von E-Mail-Benachrichtigungen, das Verkürzen von Meetings, das Einfordern von Meeting-Agendas und der Grundsatz „Nach drei E-Mails lieber anrufen“ den Arbeitstag effizienter gestalten können. Zudem betonen wir die Wichtigkeit, feste Fokuszeiten im Kalender zu planen und diese auch einzuhalten. Für die langfristige Perspektive besprechen wir Strategien wie das Setzen von regelmäßigen Terminblockern im eigenen Kalender, das Delegieren von Aufgaben und den Aufbau einer Stakeholder-Community ( https://produktwerker.de/stakeholder-community/) . Diese Ansätze unterstützen nicht nur eine bessere Zeiteinteilung, sondern auch eine effiziente und effektive Zusammenarbeit. Abschließend teilen wir einige Ratschläge, darunter die Kraft des Bullet Journals, um sich jeden Morgen auf die wichtigste Aufgabe zu konzentrieren, bevor digitale Geräte eingeschaltet werden. Außerdem betonen wir die Bedeutung eines nachhaltigen Arbeitstempos (sustainable pace), das langfristigen Erfolg sichert und das Einplanen von Pausen beinhaltet. Am Ende muss man schon fast sagen, dass keine Zeit zu haben eine Lüge ist. Ehrlicherweise heißt es nämlich oft, dass andere Sachen wichtiger sind. Wir würden uns aber freuen, wenn ihr uns schreibt, wie ihr damit umgeht keine Zeit zu haben. Was sind eure Techniken, Strategien und Tipps, die ihr mit andern Teilen könnt? Gerne hier als Kommentar oder auf LinkedIn.…
Simonetta Batteiger im Gespräch mit Oliver A Als Product Owner und Produktmanager führe ich in unterschiedlicher Art und Weise. Daher blickt Oliver in dieser Podcastfolge gemeinsam mit Simonetta Batteiger erneut auf das Thema Leadership Skills. Simonetta arbeitet als Beraterin, Trainerin und zertifizierte Coachin für Produktführungskräfte und Executives und legt dabei auch einen Fokus auf Inclusive Leadership. Denn ihrer Meinung nach ist erfolgreiche Produktarbeit Führungsarbeit. Zu Beginn des Gespräches teilt Simonetta ihre Sicht, warum Leadership für mich als Product Owner so wichtig ist. Deshalb gilt es natürlich auch zu klären, was Leadership überhaupt ist und wie das mit der Verantwortlichkeit als Produktmensch zusammenpasst. Simonetta hat in einem Talk auf den PO Days bereits drei essentielle Skills geteilt. In der Podcastfolge mit Oliver gehen die beiden auf die einzelnen Aspekte noch einmal detaillierter ein. Erstens ist es elementar, dass die Richtung in die unser Produkt entwickelt werden soll, klar ist und von allen Beteiligten verstanden wird. Als Produktmanager obliegt mir vor allem dafür zu sorgen, dass eine Vision, eine Strategie und eine Product Roadmap existiert und diese kommuniziert werden. Zweitens kann jede Führungskraft Coaching Habbits entwickeln, die in der Zusammenarbeit mit anderen Menschen helfen können. Und drittens gestalte ich das Team, mit dem ich das Produkt entwickle, auch immer bis zu einem gewissen Punkt mit. Denn in unserer Verantwortlichkeit werden wir niemals alleine agieren und alleine erfolgreich sein können Simonetta war so freundlich, uns die Slides ihres Talks von den PO Days zur Verfügung zu stellen. Bei Interesse kannst Du Dir die Folien hier herunterladen…
Tim & Dominique im Gespräch Bei den ganzen Fallen bleibt es auch nicht aus, dass wir schon die ein oder andere Folge passend dazu haben. Daher haben wir diese Folge referenziert: Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner ( https://produktwerker.de/organisatorische-schulden/ ) Wer nimmt denn nun User Stories ab? ( https://produktwerker.de/abnahme-von-user-stories/ ) Seine Stakeholder kennen und richtig analysieren ( https://produktwerker.de/stakeholder-analysieren/ ) Wie die Produktvision hilft, Product Ownern eine Richtung zu geben ( https://produktwerker.de/wie-die-produktvision-hilft-product-ownern-eine-richtung-zu-geben/ ) Sei dein eigenes Produkt ( https://produktwerker.de/sei-dein-eigenes-produkt/ ) Reflexion: Der Schlüssel zu persönlicher und beruflicher Entwicklung ( https://produktwerker.de/reflexion/ )…
D
Die Produktwerker
Oliver und Tim im Gespräch Wir haben einen Website-Relaunch vollzogen und dabei versucht, agil und inkrementell vorzugehen. Das ist aber gar nicht so einfach, weil das auch nicht jede Agentur mitmacht, die man ggf. dafür braucht. Einiges an dieser Produktentwicklung hat gut geklappt - bei anderen Sachen haben wir selbst mal wieder eine Menge gelernt. Wir berichten, welche User Probleme und Business Needs uns initial dazu gebracht haben, unser "Produkt" Website nochmal grundlegend zu überarbeiten und wie wir diese Aufgabe angegangen sind. Natürlich berichten wir auch darüber was gut geklappt hat und über unsere Fehler. Natürlich kämpfen auch wir selbst mit der Frage, wann es "gut genug" ist bzw. wann das Ergebnis unserem Anspruch genügt um live zu gehen. Tim und Oli berichten zudem, wie sie die Zusammenarbeit mit der Agentur agil gestalten konnten und welche Erfolgsmetriken sich die Produktwerker selber für den Website-Relaunch gesetzt haben. Ein großes Problem welches wir mit dem Website-Relaunch lösen wollen, ist die bessere Auffindbarkeit von unseren ganzen älteren Podcast-Folgen. Da steckt noch soviel wertvoller Content drin, aber bei nun schon 211 Episoden fand man diese "Perlen" gar nicht mehr so einfach. In den üblichen Podcast-Playern ist das eh nahezu unmöglich, aber auf unserer Website gab es halt auch nur eine unsäglich lange Liste. Also haben wir nun eine Schlagwortsuche und vor allem eine Filterung nach thematischen Kategorien eingebaut. Insbesondere zu dieser neuen Podcast-Suche wollen wir euch nun ganz herzlich um euer Feedback bitten und geben euch im Gegenzug die Chance einen tollen Preis zu gewinnen. Geht einfach auf der Website auf die Seite Podcast und klickt auf den Feedback-Button . Unser allen Einsendungen von Feedback verlosen wir einen Platz in unserem Strategietraining am 23./24.April in Köln. Zu dieser Episode passen diese älteren Folgen: Als Product Owner auf Seiten einer Agentur Zusammenarbeit mit einem UX-Dienstleister Der Product Owner aus Sicht eines Dienstleisters Wir möchten uns an dieser Stelle ausdrücklich bei unserem geschätzten Kooperationspartner Webrunners und Geschäftsführer Adrien Simon bedanken. Insbesondere gilt aber unser Dank Finja Kolzem, die für und mit uns verantwortlich die neue Seite gebaut hat. Danke für Deinen großartigen Einsatz liebe Finja! Ebenfalls geht ein großes Dankeschön an Marek Nowacki (snckbl media) für unser überarbeitetes Corporate Design. Welche Erfahrungen habt ihr evtl. schon mal bei der Erstellung einer neuen Website gemacht? Inwiefern war das für euch inkrementel machtbar und hattet ihr dafür einen passenden Dienstleister bzw. Agentur, die dabei mitgespielt hat? Wenn du deine Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Dominique & Tim im Gespräch Ist der Product Owner eine laterale Führungskraft? Hat man in der Verantwortung als Product Owner auch Führungsverantwortung? Und wenn ja, wie stellt sie sich dar? Tim und Dominique klären in dieser Episode zunächst mal die Frage, was denn unter lateraler Führung zu verstehen ist und ob man als Product Owner grundsätzlich eine Führungsrolle inne hat. Dies leben Unternehmen tatsächlich auch sehr unterschiedlich und oft hängt es auch davon ab, welches Ansehen und Rollenverständnis im Rahmen der Produktentwicklung der Product Owner Verantwortlichkeit zugestanden wird. Es kommt also sehr oft auf das Hierarchieverständnis innerhalb der Organisation an, ob ein Product Owner als laterale Führungskraft im Unternehmen wirken kann. Die Herausforderung ist dann, ohne formale Macht eine (inhaltliche) Führung zu übernehmen. Führung bezieht sich für Product Owner dann vor allem für das Produkt und die Führung im Sinne der zielgerichteten Ausrichtung des Scrum Teams auf Produktvision und Produktziele. Eine entscheidende Frage ist aber auch, wie sich die Stakeholder gegenüber der Product Owner Rolle verhalten bzw. ob sie einen Product Owner als laterale Führungskraft akzeptieren. Ferner diskutieren die beiden Produktwerker aber auch, wo laterale Führung ggf. nicht hilft oder vielleicht sogar schädlich ist. Mit einer zusammenfassenden Betrachtung der Vorteile von lateraler Führung als Product Owner schließt die Folge ab. Das Thema war übrigens ein Hörerwunsch. Wir freuen uns immer wieder, wenn ihr uns Themenvorschläge macht. Im Gespräch wird auf diese Folgen verwiesen: Das Product Operating Model von Marty Cagan Introvertiert als Product Owner - geht das? Stakeholder Community Product Principles Und diese Literaturempfehlungen gab es: Patrick Lencioni: The Five Dysfunctions of a Team Geoff Watts: Product Mastery Wie ist eure Meinung? Kann die Product Owner die Verantwortlichkeit so leben, dass er bzw. sie als laterale Führungskraft zu wirken? Sind bei euch im Unternehmen Product Owner Führungskräfte bzw. werden als solche betrachtet? Wenn du deine Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
D
Die Produktwerker
Annette Greil im Gespräch mit Dominique Diesmal hatten wir das Vergnügen, Annette Greil ( https://www.linkedin.com/in/annette-greil-7a6333107/ ) zu begrüßen, die ihr Rollenverständnis und ihre Erfahrungen als Product Coach bei der METRO.digital mit uns teilte. Product Coaching befähigt die Organisation über traditionelle Produktentwicklung hinauszugehen, um letztendlich herausragende Produkte zu entwickeln. Eine typische Woche im Leben eines Product Coaches, so Annette, gibt es eigentlich nicht. Sie verbringt ihre Zeit mit einer Vielzahl von Aufgaben, von Einzelgesprächen mit Teammitgliedern über die Moderation von Workshops bis hin zur Analyse von Produktstrategien und der Optimierung von Arbeitsabläufen. Product Coaches arbeiten intensiv mit Product Ownern, Product Managern und Product Leadern zusammen. Die erforderlichen Kompetenzen für diese Rolle sind ebenso vielfältig, einschließlich starker Kommunikationsfähigkeiten, Empathie, einem tiefen Verständnis für Produktmanagement-Praktiken und einer ausgeprägten Fähigkeit, komplexe Probleme zu lösen. Die digitale Landschaft ändert sich rasant, und als Coach muss man sich kontinuierlich weiterbilden, um auf dem neuesten Stand der besten Praktiken und Technologien zu bleiben. Annette schließt nicht nur mit einigen wertvollen Tipps für angehende Product Coaches ab, sondern wagt auch einen Blick in die Zukunft. Wie wird sich das Product Coaching in den kommenden Jahren verändern? In der Folge haben wir kurz auch auf unsere OKR Folge referenziert. Hört dort auch gerne rein, um mehr über OKR und ihre Rolle für Product Owner zu erfahren -> https://produktwerker.de/okr-product-owner/…
Dominique und Oliver im Gespräch Dominique und Oliver greifen in dieser Episode eine Frage auf, die uns vor einiger Zeit ein Zuhörer mit einem Augenzwinkern gestellt hat: “Wann lohnen sich Product Owner?” Und vor allem, wann lohnt es sich nicht, diese Verantwortlichkeit in Unternehmen zu etablieren. Aus der Diskussion ergibt sich eine gute Zusammenfassung, was aus ihrer Sicht einen Product Owner ausmacht bzw. bei welchen Rahmenbedingungen man von einem Product Owner sprechen kann. Sofern ich die im Scrum Guide formulierte Vorstellung eines POs ernst nehme, gewinnen Teams durch eine bevollmächtigte Product Owner vor allem drei Dinge: klare Verantwortlichkeit bei Produktentscheidungen, Entscheidungsgeschwindigkeit und Fokus auf die Kunden- und Unternehmenbedürfnisse. Wichtig ist hierbei, dass POs auch Produktmanager sein dürfen und können. Förderung von Agilität Als besonders wichtig stellen Dominique und Oliver heraus, dass auch ein Product Owner ein besseres Verständnis für Hypothesen getriebenes Arbeiten und Produktentscheidungen unter Unwissenheit in seinem eigenen Umfeld entwickeln kann. Auch hier kann die Einführung der Rolle lohnenswert sein. Die beiden Gesprächspartner diskutieren natürlich auch die Kehrseite der Medaille, nämlich wann Product Owner auch nicht wirklich weiterhelfen. Und wie immer schließen sie die Podcastfolge mit praktischen Tipps & Tricks aus dem eigenen persönlichen Erfahrungsschatz ab.…
Marcel Mellor im Gespräch mit Tim In dieser Folge haben wir Marcel Mellor, Product Lead von sipgate, zum Thema "Innovation im Unternehmen" zu Gast. Marcel ist Produktstratege und spannender Weise auch Science Fiction Autor, was ja per se schon nah an innovativen Themen ist. Tim diskutiert im Rahmen eines Erfahrungsberichts zum Innovationsprodukt " satellite " mit Marcel, wie Innovation im Unternehmen gelingen kann und ob und wie eine Innovation z.B. in einem sprint-basiertem Ansatz wie Scrum gut gelingen kann. Natürlich steht zu Beginn die Frage, was Innovation für Marcel bedeutet und wie er ganz persönlich zu dem Interesse an Innovationsarbeit gekommen ist? Besonders spannend sind die Learnings, die Marcel Mellor im Zuge der Innovationsreise mit dem Produkt satellite selbst für sich über Innovation gelernt hat. Die beiden diskutieren, welche Erfolgsfaktoren und Hindernisse sie für Innovation im Unternehmen sehen. Ein Bezug zu Innovation und KI darf dabei natürlich auch nicht fehlen. In Summe ist ein sehr inspirierender Erfahrungsaustausch mit einem echten Innovationsprofi entstanden. Empfohlene Quelle zum Thema Innovation im Unternehmen: Steven Johnson:- Aufzählungs-Text Wo gute Ideen herkommen: Eine kurze Geschichte der Innovation Diese alten Episoden wurden im Gespräch erwähnt: Mit Storytelling andere von Deinen Produktideen überzeugen Warum scheint die Product Owner Rolle so schwer zu sein? (mit Markus Andrezak) Business- oder Nutzersicht: Welchen Blickwinkel sollte ein PO einnehmen? (mit Markus Andrezak und Sohrab Salimi) Wenn ihr mehr Content von Marcel Mellor hören bzw. lesen wollt, folgt ihm auf LinkedIn oder hört einen seiner beiden Podcasts: Podcast: " Skalierbar " (mit David Ranftler) Podcast: Tech is Good Das aktuelle Buch von Marcel Mellor: Das Register Personal Website: marcelmellor.com Und falls ihr euch für das Product "satellite" näher interessiert, gibt's hier alle Infos . Wird echt Innovation im Unternehmen aus Deiner Sicht durch agile Frameworks wie z.B. behindert oder gefördert? Oder hälst Du die Wahl des Ansatzes für unerheblich für den Erfolg der Innovation? Falls du den einen oder anderen Aspekt deiner Erfahrungen oder Tipps & Tricks mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Dominique & Oliver im Gespräch Diese Folgen zitieren wir in der Folge:; User Story Map ( https://produktwerker.de/story-mapping/ ) Impact Mapping ( https://produktwerker.de/impact-mapping ) Stakeholdercommunity ( https://produktwerker.de/stakeholder-community/ ) Diese Folge wurde stark inspiriert durch einen LinkedIn-Post von Ant Murphy ( https://www.linkedin.com/posts/ant-murphy_8-different-ways-to-organise-your-product-activity-7153158996827246592-D5ys?utm_source=share&utm_medium=member_desktop) .…
Christian Fahl im Gespräch mit Dominique In der Folge kommen wir auf verschiedene Themen zu sprechen. Christian hatte einen Prototyp mittels No-Code-Tools erstellt. Falls euch die Möglichkeiten von No-Code interessieren empfehlen wir euch die Folge "Wie No-Code Tools Produktteams helfen" ( https://produktwerker.de/no-code-tools/) . Auch haben wir im Gespräch das Konzept eines Minimal-Viable-Product angesprochen zu dem ihr unbedingt die Folge "Das Problem mit dem Minimal Viable Product" ( https://produktwerker.de/das-problem-mit-dem-minimal-viable-product/ ) hören solltet, denn immer wieder ergeben sich aus dem Konzept Probleme. Ansonsten empfiehlt Christian noch das Buch "The 7 Habits of Highly Effective People" von Stephen R. Covey, dass im bei seiner Reise sehr geholfen hat.…
Oliver & Tim im Gespräch Gegen Ende eines jeden Jahres kommen die Thema Budget- und Roadmapplanung wieder auf die Tagesordnung. Und in die Planung dieser jährliche Roadmap werden wir als Product Owner*in dann intensiv eingebunden. Aber lohnt der Aufwand, den wir in diese Themen investieren? Tim und Oliver diskutieren diese Themen vor allem auf Basis ihrer eigenen Erfahrungen. Nachdem die beiden reflektiert haben, warum eine jährliche Planung für viele Unternehmen immer noch wichtig ist, geben sie einen kurzen Überblick über die Unterschiede zwischen Projekt- und Produkt-Roadmaps. Da aber die Mehrzahl unserer Ideen für die Produktentwicklung nicht funktionieren oder zumindest mehrere Iteration brauchen, bis sie die Business-Ziele generieren können die wir uns erhofft haben, stellt sich die Frage, ob eine jährliche Roadmapplanung auch wegen der Kompexität und Unsicherheiten im eigenen Produktkontext überhaupt sinnvoll ist. Tim und Oliver bieten in dieser Folge einige Lösungsansätze, wie man besser mit Roadmaps umgehen und arbeiten kann. Wir immer teilen die beiden zum Abschluss der Episode Tipps und Tricks.…
Andreas Hinderks im Gespräch mit Dominique Der Berufsstand der UX-Professionals hat in den letzten Jahren eine Differenzierung erlebt, und es sind neue Teildisziplinen entstanden. Eine dieser Disziplinen ist das UX-Management, und mittlerweile gibt es einige Menschen, die die Verantwortung als UX-Manager in Projekten und Organisationen übernehmen. Durch ihre Arbeit prägen sie die Produktentwicklung; es lohnt sich also zu fragen, was das genau ist und wie diese Disziplin Menschen in Verantwortungspositionen als Product Owner, Product Manager oder Product Lead bei der Entwicklung großartiger Produkte unterstützt. Dazu haben wir den UX-Experten Andreas Hinderks eingeladen, der nicht nur beruflich viel mit dem Thema zu tun hat, sondern auch intensiv dazu forscht. Wir klären also zunächst, was UX-Management ist, was manche vielleicht darunter verstehen und wie sich diese Tätigkeit in den Kontext der Produktentwicklung einfügt. Dabei wird schnell deutlich, dass Management nicht ohne Strategie, Ziele und Ressourcen gedacht werden kann. Für Produkte sollten also idealerweise Ziele für eine gute UX gesetzt, eine Strategie zur Zielerreichung festgelegt und die angemessenen Ressourcen zugeteilt werden. Dass dies am besten im Team funktioniert, versteht sich fast von selbst, denn es geht um die Schaffung von Erlebnissen für Menschen. Natürlich tauschen wir uns mit Andreas auch über gute und schlechte Praktiken aus, damit nicht dieselben Fehler wiederholt werden müssen. Nach einigen Prognosen zur Zukunft des UX-Managements gibt Andreas zum Schluss noch einige weitere hilfreiche Tipps zum Thema UX-Management für Product Owner.…
Dominique und Tim im Gespräch Velocity ist in der agilen Softwareentwicklung, vor allem in Scrum, weit verbreitete Metrik, die die Arbeitsmenge eines Teams in einem Sprint misst. Aber ihre Nutzung birgt auch bestimmte Grenzen, die Tim und Dominique in dieser Folge kritisch hinterfragen. Velocity, meist in Story Points gemessen, gibt an, wie viel ein Team in einem (durchschnittlich) Sprint leistet. Sie ist hilfreich für die Sprint-Planung und kann die Vorhersagbarkeit verbessern. Doch als reine Output-Metrik vernachlässigt sie wichtige Aspekte wie Outcome und die Qualität der Arbeit. Ein kritischer Punkt, den Tim und Dominique betonen, ist, dass Velocity eine relative Größe ist, die nur innerhalb eines Teams Bedeutung hat. Der Vergleich von Velocity zwischen verschiedenen Teams ist problematisch und kann vorsichtig gesagt mindestens zu Missverständnissen führen. In der Diskussion heben die beiden hervor, dass Teams Velocity als Werkzeug zur Reflexion nutzen sollten, nicht als starres Ziel. Es geht darum, den tatsächlichen Wert und die Qualität der Arbeit zu verbessern - nicht um die reine Liefergeschwindigkeit als Selbstzweck. Andere Metriken, die Kundenzufriedenheit und Outcome zu messen, erscheinen sogar wichtiger zu sein. Interessanter Weise wurde die Velocity früher in Scrum Trainings viel stärker betont. Zusammen mit dem allgemeinen Trend, mehr Wert auf Outcome bzw. Wirkung zu legen, statt eine reine Product Delivery zu fokussieren, wird auch in den Trainings immer seltener über Velocity gesprochen. Neben den Problemen und Fehlern im Umgang mit Velocity betrachten Dominique und Tim natürlich auch die Vorteile des Einsatzes dieser Metrik. Weiterhin geben sie Tipps zum richtigen Einsatz von Velocity. In dieser Folge wird auf diese Episoden im Gespräch verwiesen: Wann ist das fertig? Keine Ahnung, wir sind ja agil! Forecasting in der agilen Produktentwicklung Evidence Based Management - eine empirische Suche nach Wert Nutzt ihr bei euch Velocity als Metrik? Wenn ja, wie gelingt es euch, dass diese Metrik auch positiv im Hinblick auf den Wert des entwickelten Produkts wirkt und nicht zu einem Team-Kontrollinstrument verkommt? Falls du den einen oder anderen Aspekt deiner Erfahrungen oder Tipps & Tricks mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
D
Die Produktwerker
Zum Jahresanfang bietet sich oft das Setzen von persönlichen Zielen an Zu Beginn des Jahres bietet es sich an einmal Gedanken zu den eigenen, ganz persönlichen Zielen im neuen Jahr zu machen. In dieser Folge teilt Dominique eigene Erfahrungen und Tipps rund um das Setzen effektiver, persönlicher Ziele – sowohl für das Produkt als auch für die persönliche Entwicklung. Das Setzens von Zielen ist entscheidend, um einen klaren Fokus zu erzeugen. Ein zentrales Thema ist schon ein echter Klassiker: smarte Ziele. Diese Methode hilft dabei, Ziele zu definieren, die spezifisch, messbar, erreichbar, relevant und zeitgebunden sind. Ein besonderer Fokus liegt darauf, wie diese Prinzipien auf die einzigartigen Herausforderungen von Product Ownern und Product Leadern angewandt werden können. Persönliche Ziele, die greifbar und messbar werden, können in der Regel besser erreicht werden. Gerade Produktverantwortlichen müsste es besonders leicht fallen diese Ziele anschließend auch zu bewerten und in eine Reihenfolge zu bringen. Für die persönliche Entwicklung bedeuten klare Ziele: Von der Steigerung spezifischer Kompetenzen bis hin zur Bedeutung von Work-Life-Balance mit den richtigen Maßnahmen die richtigen Schritte gehen. Vielzuoft entscheiden sich Menschen für kurzfristige Belohnungen und vbergessen dabei, dass längerfristige Ziel im Blick zu behalten. Dazu wurden in dieser Folge einige praxisnahe Tipps und Methoden geteilt. Vorgestellt wurden verschiedene Tools und Apps zur Zielverfolgung sowie Zeitmanagement-Strategien, die speziell für die Bedürfnisse von Product Ownern und Product Leadern zugeschnitten sind.…
D
Die Produktwerker
Zum Jahresende bietet sich oft eine persönliche Reflexion an In dieser besonderen Zeit des Jahres, wo wir einen Moment innehalten und das Vergangene reflektieren, möchte ich meine Gedanken und Erfahrungen zum Thema Reflexion mit euch teilen. Diese Zeilen begleiten unsere Podcastfolge, in der Dominique ausführlich über Reflexion spricht, ein Thema, das unserer Meinung nach für Product Owner, Product Manager und Product Leads gleichermaßen relevant ist. Reflexion ist ein wesentlicher Bestandteil des agilen Produktmanagements, bekannt durch Praktiken wie die Retrospektive. Es geht um mehr als nur das Zusammenfassen vergangener Ereignisse; es ist eine Gelegenheit, aus Erfahrungen zu lernen und sich persönlich sowie beruflich weiterzuentwickeln. Für uns ist es wichtig, regelmäßig innezuhalten und sowohl berufliche als auch private Erlebnisse zu reflektieren. Dominiques Reflexionstechniken, die er gerne empfiehlt: Das weiße Blatt: Hierbei man sich stumpf mit einem leeren Blatt Papier hin und notiert alles, was einem zum vergangenen Jahr einfällt. Dies kann zu einer Mindmap oder Sketch Note werden und hilft, die eigenen Gedanken zu ordnen und neue Perspektiven zu gewinnen. Klingt irgendwie zu simpel aber hilft. Reflektionsgespräche: Diese Gespräche führt man mit vertrauten Personen, um Feedback zu bekommen und die eigenen Gedanken weiterzuentwickeln. Es geht hierbei nicht nur um Kritik, sondern um das Erkennen neuer Möglichkeiten und das Ausloten unterschiedlicher Perspektiven. In der Regel reichen zwei bis drei Gespräche. Die persönliche Retrospektive: Nicht nur am Jahresende sondern einmal im Monat kann man sich die Zeit nehmen für eine tiefgehende Reflexion der eigenen Aktivitäten und Entscheidungen. Dies beinhaltet das Durchgehen des eigenen Kalenders und Trello-Boards, um zu verstehen, was man erreicht hat und was noch aussteht. Reflektieren allein genügt nicht. Es geht darum, Konsequenzen aus den eigenen Erkenntnissen zu ziehen. Das bedeutet, Entscheidungen zu treffen, Ziele zu setzen und konkrete Maßnahmen zu ergreifen, um das Beste aus der eigenen Zeit und den eigenen Fähigkeiten herauszuholen. Und nach einer intensiven Reflexionsphase ist es wichtig, sich auch zu belohnen. Das kann eine Aussicht auf neue Ziele sein, eine kleine Freude wie ein leckeres Essen oder einfach die Zufriedenheit, sich selbst Zeit und Raum für persönliches Wachstum gegeben zu haben. Wir hoffen, dass diese Einblicke euch als Impulse dienen und euch gleichzeitig ermutigen die notwendige Zeit für Reflexion zu nehmen. Nutzt die ruhige Zeit zwischen den Jahren, um über das vergangene Jahr nachzudenken und Pläne für die Zukunft zu schmieden. In diesem Sinne wünschen wir euch besinnliche Feiertage und einen guten Start ins neue Jahr!…
D
Die Produktwerker
Tim und Dominique im Gespräch Was ist ein Produkt? Und ist eine Dienstleistung ein Produkt? Beides sind oft gehörte Fragen. Dominique und Tim greifen diese Fragen auf und diskutieren in dieser Episode rund um den Produktbegriff. Zunächst gucken sie sich gängige Definitionen an. Ein übliches Produktverständnis umfasst auch Services bzw. Dienstleistungen. Oft fällt es Organisationen aber noch schwer, die Frage zu klären "Was ist ein Produkt" und wie schneiden wir dementsprechend die jeweiligen Teams rund um die Produkte. Aber was ist, wenn ich als Product Owner nach diesen Definitionen gar kein "Produkt" habe? Vielleicht verantwortet man also eine Komponente, ein Feature oder eine Plattform. Kann man dann dennoch produkthaft vorgehen? Und was ist mit internen Produkten? Sind das eher Anwendungen oder kann man sie auch als Produkt bezeichnen? In diesem Zusammenhang diskutieren die beiden auch kurz, ob und wann eine API ein Produkt ist und wann nicht. Am Rande sprechen die beiden auch nochmal über die Abgrenzung von Nutzer und Kunde. Auch hier werden in der Praxis die Begriffe oft etwas zu nachlässig verwandt. Empfohlene Quellen zur Frage "Was ist ein Produkt": Marty Cagan (svpg): What is a Product? Definition "Was ist ein Produkt" aus dem Scrum Guide Roman Pichler " Six Types of a "Product" Owner " In dieser Episode empfohlene Podcast Folgen: Vom Projektleiter oder Teamleiter zum Product Owner Scrum Product Owner vs. SAFe Product Owner - ein Missverständnis Wardley Mapping - Produktstrategie wie ein Schachspiel POEM - Product Ownership Evolution Model Evidence Based Management - eine empirische Suche nach Wert Kennst du diese Fragestellung "Was ist Produkt"? Wird die Diskussion bei euch auch im Rahmen des Produktschnitts geführt? Wie definiert ihr eure Produkte? Und wie geht ihr mit Dienstleistungen bzw. Services um? Falls du den einen oder anderen Aspekt deiner Erfahrungen oder Tipps & Tricks mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Thomas Gläser im Gespräch mit Tim "Wir werden das Produkt einstellen - es ist zwar noch erfolgreich, passt aber nicht mehr zur künftigen Unternehmensstrategie." Wenn man solch eine Entscheidung hört, ist klar, dass das Ende des Produktlebenszyklus naht. Aber bis dahin ist ja eben auch noch ein Weg zu gehen, für den es ein motiviertes Team braucht. Der Ramp Down eines Produktes gehört schließlich unzweifelhaft auch zur Produktentwicklung. Zu Beginn des Jahres hat XING (bzw. die New Work SE) die durchaus erfolgreichen Produktbereiche XING Events und XING Gruppen eingestellt, um die eigenen Kräfte zu bündeln und den Fokus auf die neu gewählte Strategie zu legen. Ein wirklich mutiger Schritt. Unser heutiger Gast Thomas Gläser, Director Product Experience bei der New Work SE, hat dies hautnah miterlebt und musste (oder wohl besser gesagt "durfte") diese spannende Phase als verantwortlicher Product Leader begleiten. Im Gespräch mit Tim berichtet er, wie er die Motivation für die letzte Produktphase im Team hochgehalten hat und wie er sich selbst dabei gefühlt hat. Eine spannende Diskussion über eine Erfahrung, die nur wenige Produktmenschen machen dürfen. Im Gespräch werden die folgenden Quellen genannt: Killed by Google Liberating Structures: Ecocycle Planning Aufräumen mit Methode: Analogie zu Marie Kondo Buch von Ernest Becker: The Denial of Death Zu dieser Episode passt auch gut diese ältere Folge: Features wegwerfen - was braucht es dafür außer Mut? Wer mit Thomas Gläser in Kontakt treten möchte, guckt sich am Besten mal seine persönliche Webseite (thomasglaeser.de) an oder folgt ihm auf LinkedIn. Dort teilt er regelmäßig seine Gedanken zu Produktthemen und über die diversen Veranstaltungen auf denen er aktiv ist. Zudem freut sich Thomas zur Kontaktaufnahme auch über eine direkte E-Mail an ich@thomasglaeser.de. Hast du auch schon mal die Erfahrung "Produkt einstellen" gemacht? Welche Überlegungen gab es bei euch? Welche Befürchtungen hattest du, die sich am Ende vielleicht gar nicht eingestellt haben? Falls du den einen oder anderen Aspekt deiner Erfahrungen oder Tipps & Tricks mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Jacob Pawlik im Gespräch mit Dominique Für Product Owner spielt die tägliche Interaktion mit Softwareentwicklern eine Schlüsselrolle. Sie sind die Stakeholde, mit denen wir im täglichen Arbeiten mit am häufigsten zu tun haben. Von den ganzen Diskussionen über die Absprachen zu Anforderungen bis hin zu gemeinsamen Entscheidungen – die Dynamik dieser Beziehung beeinflusst wesentlich den Erfolg der Produktentwicklung. Um tiefer in diese Beziehung einzutauchen hat Dominique in dieser Folge das Vergnügen, mit Jacob Pawlik ( https://www.linkedin.com/in/jacob-pawlik/ ) zu sprechen. Jacob ist Head of WebTec bei der Scopevisio AG und bringt eine wertvolle Perspektive in unser Gespräch ein: die Erwartungen von Entwicklern an Product Owner. Hauptthemen unserer Diskussion: Entwicklererwartungen: Was genau erwartet ein Developer von einem Product Owner? Jacob beleuchtet diese Frage aus seiner Erfahrung. Produktvision: Wie wichtig ist die Produktvision aus der Sicht eines Entwicklers und wie beeinflusst sie die tägliche Arbeit? Augenhöhe und Hierarchien: Warum sind diese Aspekte entscheidend und wie sollte man mit ihnen umgehen, um eine effektive Zusammenarbeit zu fördern? Red Flags in der Zusammenarbeit: Jacob teilt seine Einsichten darüber, was in der Zusammenarbeit mit einem Product Owner als Warnsignal gelten kann. Refinement, Planning und Review: Was braucht ein Product Owner wirklich für diese Prozesse? Was erwartet ein Entwickler in diesen Phasen? Die Retrospektive mit Product Ownern: Ein Blick auf die Bedeutung und Durchführung effektiver Retrospektiven. No-Gos für Product Owner: Jacob spricht über häufige Fehler, die Product Owner vermeiden sollten. Tipps zur Verbesserung der Zusammenarbeit: Abschließend gibt Jacob praktische Ratschläge, wie Product Owner die Zusammenarbeit mit Entwicklern verbessern können. Diese Episode bietet tiefe Einblicke in die Beziehung zwischen Product Ownern und Entwicklern. Wir hoffen, dass ihr diese Folge genauso aufschlussreich findet wie wir. Aber vielleicht habt ihr auch andere Erfahrungen gemacht oder habt eine abweichende Meinung. Lasst es uns gerne wissen. Entweder als Kommentar zum Blogpost dieser Folge oder bei einem der Posts auf Social Media.…
Thomas Götten im Gespräch mit Tim Wenn Unternehmen nicht genügend interne Product Owner haben, beauftragen sie zunehmend Interim Product Owner. Meist wird dabei in Form eines zeitlich befristeten Projektauftrags (der idR mehrfach verlängert wird), eine Person gesucht, die als Product Owner woanders schon Erfahrung gesammelt hat. Das beauftragende Unternehmen erhofft sich so Methodenwissen über die Verantwortlichkeit ("Rolle") von außen in die Firma zu bekommen. Aber auch wenn dabei versucht wird, jemanden mit fachlicher Erfahrung des eigenen spezifischen Produktkontexts oder Branche zu finden, gelingt dies nur selten. Denn tatsächlich erscheinen zum einen gar nicht so viele (erfahrene) externe Product Owner verfügbar zu sein - und dass dann auch noch der fachliche Kontext passt, erscheint eher wie ein glücklicher Zufall. Wir haben uns daher Thomas Götten eingeladen, der als Selbständiger solche Aufträge als "Technischer Product Owner" übernimmt. Zum einen will Tim natürlich erstmal verstehen, was das Besondere an einem technischen Product Owner für Thomas ist. Als Product Owner in Festanstellung hatte Thomas viele Jahre Erfahrung sammeln können und ist fest "methodenfest". Das wissen wir, weil wir ihn schon recht lange kennen. Aber vielleicht ist das ja eben auch besonders wichtig, wenn man als Interim Product Owner arbeitet - schließlich darf man sich ja auch nicht vom System des Auftraggebers "verbiegen" lassen, so dass man letztlich als eine Art Zombie Product Owner endet. Es folgt eine spannende Diskussion über Vor- und Nachteile, kein explizites Fachwissen in der Kundendomäne mitzubringen. Natürlich muss man offen und aufgeschlossen sein, aber eine der Schwierigkeiten ist ja allein schon die Akzeptanz bei den Mitarbeitenden beim Kunden. Thomas berichtet von seinen spannenden Erfahrungen bei einem Spielzeughersteller und v.a. aus dem noch ungewöhnlicheren Feld der internationalen Kunstlogistik. Bei einem solch spitzen Produkt stellt sich die Frage nach Externen mit Branchenerfahrung vermutlich noch nicht einmal. Thomas Götten teilt also seine eigenen Learnings aus den letzten Aufträgen als Interim Product Owner und die beiden diskutieren u.a. die folgenden Fragen: Hast man als externer PO die gleichen "Rechte" & "Pflichten" wie ein interner PO? Wie geht man mit "Erbe" um - also wenn ein volles Product Backlog etc. übernommen werden muss, welches man ggf. gar nicht komplett versteht. Wieviel "Invest" in Team, Beziehung etc, lohnen sich, wenn man als Externer unterwegs ist und die Aufträge i.d.R. zwischen 6 und 12 Monaten dauern? Auf diese älteren Episoden unseres Podcasts verweisen Tim und Thomas im Laufe des Gesprächs: Dein Freund der Scrum Master Was die Einführung von OKR für Product Owner bedeutet Wieviel technisches Wissen muss ich als Product Owner haben? Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner Event Storming: Verständnis für komplexe Produkte schaffen Wer weitere Fragen an Thomas Götten hat oder mit ihm in Kontakt treten möchte, erreicht ihn am Besten über sein LinkedIn-Profil oder über seine Webseite joettis.com bzw. via E-Mail. Hast du schon Erfahrungen mit Interim Product Ownern gesammelt? Wie lief der Einsatz eines zeitlich befristeten Product Owner bei euch ab? Oder warst du wie Thomas selber schon als externer Product Owner ohne Domänenwissen im Einsatz? Wir sind gespannt, von euren Ergebnissen zu hören! Falls du den einen oder anderen Aspekt deiner Insights oder Tipps & Tricks mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Christoph Herrmann im Gespräch mit Tim Diesmal wollen wir uns der besonderen Herausforderung der Entwicklung einer Omnichannel widmen. Unser Gast Christoph Herrmann ist Head of Product der Kaufland-App bei Kaufland E-Commerce. Im Gespräch mit Tim gibt er einen Erfahrungsbericht, was die Entwicklung eines digitalen Produkts, also einer App, im Kontext des stationären Handels so besonders macht. Da die App im Rahmen der Omnichannel-Strategie von Kaufland auch im Markt bzw. ganz konkret "am Regal" zum Einsatz kommt, werden hier die Grenzen eines typischen Digitalprodukts deutlich verlassen. Es geht also um sehr unterschiedliche Zielgruppen und die Verzahnung mit den Handelsprozessen in den Märkten. Dies führt natürlich zu besonderen Herausforderungen bei Product Discovery, User Feedback Zyklen usw. und macht eine solche Produktentwicklung schon etwas spezieller. Darüber sprechen Christoph Herrmann und Tim Klein in dieser Folge - nachdem erstmal die Frage geklärt wurde, was überhaupt der Begriff Omnichannel bedeutet. Um folgende Themen geht es danach: Wie laufen Sprint Reviews ab? Wie gelingt die Zusammenarbeit mit Stakeholdern? Sicherlich kann man aus diesen Fragestellungen auch dann wichtige Impulse ziehen, wenn man nicht im Omnichannel-Umfeld unterwegs ist. Zu dieser Episode passt auch gut die Folge " Wieviel technisches Wissen muss ich als Product Owner haben? " Wer weitere Fragen an Christoph Herrmann hat oder mit ihm in Kontakt treten möchte, erreicht ihn am besten über sein LinkedIn-Profil . Bist du an der Entwicklung eines ähnlichen Produkts beteiligt? Müsst ihr auch, im Rahmen einer Omnichannel Strategie neben den digitalen Kanälen den stationären Handel im Auge behalten? Welche Herausforderungen sind da bei euch aufgetreten? Wie habt ihr das gut in den Griff bekommen? Falls du den einen oder anderen Aspekt deiner Insights oder Tipps & Tricks mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Florian Holzhäuser im Gespräch mit Dominique Die Integration von UX-Professionals in ein Scrum-Team stellt eine echte Herausforderung dar und erfordert ein tiefes Verständnis für die verschiedenen Charaktere, die in diesem Prozess auftreten können. In dieser Folge spricht Dominique mit Florian Holzhäuser ( https://www.linkedin.com/in/florian-holzh%C3%A4user-1429b113b/ ) von IT Sonix ( https://www.itsonix.eu/ ) über seine Erfahrungen und Erkenntnisse, um diese Herausforderung zu meistern. Florian identifizierte vier mögliche Charaktere, wie UX-Professionals ins Scrum-Team eingebunden werden können: Prediger, Mentor, Macher und Daywalker. Jeder dieser Charaktere bringt unterschiedliche Perspektiven und Fähigkeiten mit sich, die sich auf die Art der Zusammenarbeit im Scrum-Team auswirken können. Der Charakter hängt dabei von verschiedenen Faktoren ab, darunter das verfügbare Budget und die Menge der Arbeit. Der "Prediger" ist jemand, der leidenschaftlich die Bedeutung von UX im Entwicklungsprozess predigt. Dieser Charakter kann dazu beitragen, das Bewusstsein im Team zu schärfen und die Bedeutung einer benutzerzentrierten Herangehensweise zu betonen. Die Integration eines Predigers kann besonders nützlich sein, wenn das Team wenig Erfahrung mit UX hat und einen Anstoß für einen Paradigmenwechsel benötigt. Der "Mentor" spielt eine Schlüsselrolle bei der Anleitung und Schulung des Teams im Bereich UX. Dieser Charakter bringt nicht nur Fachkenntnisse, sondern auch didaktische Fähigkeiten mit sich. Durch den Mentor können Teammitglieder ihre Fähigkeiten im Bereich UX verbessern, was langfristig zu einem selbstständigeren und kompetenteren Team führen kann. Der "Macher" ist jemand, der direkt an den UX-Aufgaben arbeitet und praktische Lösungen liefert. Dieser Charakter ist besonders effektiv, wenn schnelle Ergebnisse erforderlich sind und das Team direkte Unterstützung in der Umsetzung von UX-Praktiken benötigt. Die Integration eines Machers kann jedoch budgetintensiver sein, da möglicherweise mehr Ressourcen benötigt werden. Schließlich gibt es den "Daywalker", der flexibel zwischen den verschiedenen Welten wechseln kann. Dieser Charakter ist anpassungsfähig und kann je nach den Anforderungen des Teams in verschiedene Rollen schlüpfen. Die Integration eines Daywalkers kann die Flexibilität des Teams verbessern und sicherstellen, dass die UX-Professionals nahtlos in den Scrum-Prozess integriert werden. Insgesamt verdeutlicht diese Diskussion, dass die Integration von UX-Professionals in Scrum-Teams nicht nur eine organisatorische Herausforderung ist, sondern auch eine Chance bietet, die Qualität der Produkte durch eine stärkere Fokussierung auf die Benutzererfahrung zu verbessern. Es wird deutlich, dass die Vielfalt der Charaktere innerhalb der UX-Professionals einen positiven Einfluss auf die Agilität und Effektivität von Scrum-Teams haben kann.…
Dominique & Tim im Gespräch Eine Organisation beginnt agil zu arbeiten und benötigt dann Product Owner:innen. Oft werden ehemalige Projektleiter oder Teamleiter als Product Owner:innen bestellt. Dass sich durch diese Veränderung bestimmte Herausforderungen ergeben, liegt nahe. Dies zeigt sich auch in eurem Wunsch, sich einmal über dieses Thema zu unterhalten. Daher sprechen in dieser Folge Dominique und Tim über den Übergang von der alten Verantwortung zur neuen. Im Gespräch wird schnell deutlich, dass es einige Verhaltensweisen gibt, die Projektleiter:innen durchaus hilfreich sein können, aber auch andere, die Schwierigkeiten verursachen. Projektleiter:innen sind oft sehr auf die Auslieferung fokussiert, wobei der Output über dem Outcome steht. Auch die direkte Zuweisung von Aufgaben an Personen mag Projektleiter:innen nützlich sein, aber im agilen Kontext als Product Owner wird dieses Verhalten nicht gut funktionieren. Ähnliches gilt auch für Teamleiter:innen. Die Aufgaben der Personalentwicklung und der Personalbeschaffung fallen schlichtweg weg, sobald man die Verantwortung als Product Owner übernimmt. Das macht den Wandel nicht so einfach. Dabei kann vor allem Transparenz helfen. Damit ist nicht nur die Zusammenarbeit mit dem Team und den Stakeholdern gemeint, sondern auch die persönliche Reflexion. Ehemalige Rollenmuster müssen bewusst umgedeutet werden. Feedbackgeber wie das Team, insbesondere im Rahmen der Retrospektive, und Menschen in der Verantwortung als Scrum Master können dabei hilfreich sein. Diese spielen eine besonders wichtige Rolle, weshalb eine agile Transformation ohne Scrum Master, besonders für Personen aus den vorherigen Rollen als Projektleiter oder Teamleiter, schwierig ist. Dennoch ist eine solche Veränderung gut möglich. Im Gespräch wurde auf folgende Folgen verwiesen: POEM – Product Ownership Evolution ( https://produktwerker.de/poem-product-ownership-evolution-model/ ) Sei dein eigenes Produkt! – als PO seine Weiterentwicklung steuern ( https://produktwerker.de/sei-dein-eigenes-produkt/ ) Außerdem erwähnten die beiden noch folgende Quellen: Das Role Model Canvas Blogpost von Roman Pichler " Be a Balanced Product Leader not a Feature Broker or Product Dictator " Blogpost von Roman Pichler " Six Types of “Product” Owners ” Wenn ihr selbst aus der Projekt- oder Teamleitung heraus in die Verantwortung als Product Owner gekommen seid freuen wir uns über eure Erfahrungen. Teilt sie gerne im Blogpost zur Folge als Kommentar oder auf unserer LinkedIn-Companyseite als Kommentar. Diese Folge ist übrigens auch unsere Antwort auf eine Frage aus der Community. Wenn auch ihr eine Frage habt, die wir in einer Folge unbedingt mal beantworten sollten, lasst es uns gerne wissen. Schickt dazu gerne eine Mail an feedback@produktwerker.de. Wir freuen uns auf eure Fragen!…
Dominique & Tim im Gespräch Eine Frage, die immer wieder aufkommt, ist die nach dem notwendigen technischen Wissen, dass man in der Verantwortung als Product Owner braucht. Dominique und Tim stellen sich in dieser Folge diese Frage und teilen ihre Erfahrungen sowie ihre Einschätzung dazu. Dazu muss man sich zuerst fragen, warum die Frage nach dem technischen Verständnis eigentlich aufkommt. Das kann einerseits an dem zugang zur Verantwortung als Product Owner liegen. Wenn man vorher in verwandten Rollen wie beispielswerise Business Analyst, oder Softwareentwickler gearbeitet hat, bringt man fast schon natürlich ein technisches Verständnis mit. Das könnte zumindest ein Grund sein, warum viele Product Owner bereits ein solches Verständnis haben und dadurch die Erwartungshaltung ihres Umfeldes entsprechend prägen. Ob das technische Verständnis aber immer hilft ist auch fraglich. Immerhin hat das Team in ihrer Domäne Expertenwissen und so manch ein Product Owner kann nicht aus der eigenen Haut und will mitmischen. Am Ende geht es aber in erster Linie darum, dass die Menschen, die zusammen versuchen ein erfolgreiches Produkt zu entwicklen miteinander sprechen können. Sie müssen sich gegenseitig verstehen. Daher ist ein sehr grundsätzliches technisches Verständnis durchaus hilfreich. Es muss nicht umfangreich sein und ein Informatikstudium ist garantiert zu viel des Guten. Wir haben in dieser Folge auf folgende Folgen verwiesen: Stellenausschreibungen für Product Owner ( https://produktwerker.de/product-owner-stellenausschreibungen/ ) Vom Entwickler zum Product Owner ( https://produktwerker.de/vom-entwickler-zum-produkt-owner/ ) Wie No-Code Tools Produktteams helfen ( https://produktwerker.de/no-code-tools/ ) Darüber hinaus haben wir folgende Quellen genutzt: Six types of a “product” owners von Roman Pichler ( https://www.romanpichler.com/blog/six-types-of-product-owners/ ) The Product Trio von Teresa Torres ( https://www.producttalk.org/2021/05/product-trio/ ) Code it! (Coding Courses for Kids) ( https://code-it-studio.de/ ) Diese Folge ist unsere Antwort auf eine Frage aus der Community. Wenn auch ihr eine Frage habt, die wir in einer Folge unbedingt mal beantworten sollten, lasst es uns gerne wissen. Schickt dazu gerne eine Mail an feedback@produktwerker.de. Wir freuen uns auf eure Fragen!…
Stefan Vosskötter im Gespräch mit Tim "Ich denke die Konferenz als Produkt - nicht nur als das Event, denn ich bin auch als Gründer immer schon in der Produktmanager-Rolle gewesen" sagt unser heutiger Gast Stefan Vosskötter, Founder und Gründer, u.a. vom Digitale Leute Summit. Aus Sicht der Teilnehmenden ist eine Konferenz vermutlich vor allem ein Lernprodukt, eine Vernetzungsplattform oder halt ein großes Partyerlebnis. Aber aus Anbieter- und Veranstaltersicht stehen wohl oft eher der Event-Charakter und die Herausforderungen das Event Managements im Vordergrund. Doch wenn eine Konferenz über Jahre erfolgreich ist und auch den unterschiedlichsten Rahmenbedingungen des Marktes oder der Gesellschaft (z.B. Pandemie) trotz, dann hilft es eine Konferenz als Produkt zu verstehen. bUnd aus diesem Blickwinkel der Produktentwicklung betrachtet Tim Klein heute mit seinem Gast Stefan Vosskötter die Entwicklung einer Konferenz. Wie ist es zu der Idee gekommen? Was ist die Produktvision, wie ist die Wettbewerbssituation, welche Zielgruppen spreche ich an? Dies mögen noch die eher üblichen Fragestellungen bei der Organisation einer Konferenz sein. Und diese Fragen lassen sich im Zweifel auch auf Inhouse Konferenzen und Veranstaltungen übertragen. Doch die Unterhaltung der beiden geht deutlich darüber hinaus und beleuchtet die folgenden Fragen: Welche Hypothesen standen zu Beginn im Raum? Welche Experimente habt ihr durchgeführt? Welche davon waren erfolgreich? Welche sind fehlgeschlagen oder sogar krachend gescheitert? Welche grundsätzlichen Learnings habt ihr über die Jahre gemacht - insbesondere aus der Remote-Zeit? Was sind eigentlich Features eines Konferenzproduktes? Wie sieht die Roadmap des Produkts aus? Und wie lässt sich ein Produkt denn überhaupt hypothesenbasiert entwickeln, welches nur einmal im Jahr eine Iteration ausgeliefert wird? Aus dieser Betrachtung einer Konferenz aus dem Blickwinkel der Produktentwicklung lassen sich daher auch sicherlich spannende Impulse für das eigene Produkt ableiten. Also: einfach mal über den Tellerrand schauen - bzw. hier "hören"! Weitere Erfahrungsberichte über die Entwicklung nicht ganz alltäglicher Produkte findet ihr in diesen früheren Episoden: Product Owner für mein Buch - ein Erfahrungsbericht Meine Erfahrung als Product Owner von JOYclub Wer weitere Fragen an Stefan Vosskötter hat oder mit ihm in Kontakt treten möchte, erreicht ihn am Besten über sein LinkedIn-Profil . Neugierig bzgl. des Digitale Leute Summit und den StartUp-Aktivitäten von Stefan geworden? Dann gibt es weitere Infos unter digitale-leute.de bzw. deutsche-startups.de . Dass wir viele Konferenz- und Eventveranstalter in der unserer Hörerschaft haben glauben wir zwar nicht. Aber vielleicht organisierst du ja stattdessen eine Inhouse Konferenz, einen Learning Day, Agile Day oder ähnliches bei euch im Unternehmen? Betrachtet ihr dabei auch diese Konferenz als Produkt? Falls du den einen oder anderen Aspekt deiner Insights oder Tipps & Tricks mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Oliver und Tim im Gespräch POEM steht für "Product Ownership Evolution Model" wurde 2017 von den beiden Produktwerkern Oliver Winter und Tim Klein erfunden und entwickelt. Es ist ein Modell, welches hilft mehr Product Ownership in einer Organisation zu etablieren. Es unterstützt dabei, die aktuell gelebte und zukünftig angestrebte Ausgestaltung der Product Ownership, vor allem im Sinne der Entscheidungsverantwortung, zu visualisieren, zu diskutieren und so gemeinsam weiterzuentwickeln. Auf diesen Ergebnissen aufbauend kann das Modell genutzt werden, um Verantwortlichkeiten für die Product Ownership zwischen den Rollen verbindlich(er) zu vereinbaren. Letztlich kann so auch ein möglicher Coaching-Bedarf der handelnden Personen/Rollen identifiziert werden, den Scrum Master und/oder Agile Coaches abdecken müssen. Oliver Winter und Tim Klein, die beiden Erfinder des Models, beleuchten in dieser Episode noch mal die Entstehungsgeschichte von POEM und welches Problem sie dazu führte, die Fragestellung von Entscheidungsverantwortung expliziter machen zu wollen. Die beiden erklären die Idee hinter dem Tool und erläutern Aufbau und Mechanik des Modells. Weiterhin beleuchten Sie seine Stärken und Schwächen und geben insbesondere Tipps und Hinweise, wie man POEM als Hilfsmittel in der Diskussion besonders effektiv einsetzen kann. So können insbesondere Scrum Master, Agile Coaches und Organisationsentwickler:innen - aber natürlich auch Product Owner - das Modell wirkungsvoll einsetzen. Download des POEM Templates inkl. Erklärungen zur Anwendung hier: produktwerker.de/poem/ In dieser Episode empfohlene Podcast Folgen: Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner Welche Aufgaben gehören zur Product Owner Rolle? (POCC - Product Ownership Context Canvas) Wie No-Code Tools Produktteams helfen können Tim's Gastauftritt zu POEM und POCC im Podcast "Mein Scrum ist kaputt" (Folge 103) Die Produktwerker veranstalten auch offene Trainings - hier die Liste der nächsten Trainingstermine Auswahl von Videos zum Product Ownership Evolution Model Aufzeichnung Produktwerker Live-Event : Product Ownership mit POEM klären Talk beim Telekom Agilista Barcamp 2020 : "POEM - Product Ownership Evolution Model" Tools4AgileTeams 2017 : "POEM – Product Owner Evolution Model" Bücher, in denen POEM empfohlen wird: Frank Düsterbeck, Ina Einemann: Product Ownership meistern Sabina Lammert et al.: Das große Handbuch Digitale Transformation : 222 Methoden und Instrumente für mehr Wandlungsfähigkeit im Unternehmen Wie sind deine Erfahrungen mit Product Ownership? Wie macht ihr die Verteilung von Entscheidungsverantwortung explizit? Habt ihr dabei vielleicht sogar schon einmal POEM (Product Ownership Evolution Model) genutzt? Welche Erfahrungen habt ihr dabei gemacht? Hat sich durch den Einsatz etwas an der Diskussion des Themas verändert? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Daniel Dubbel im Gespräch mit Tim Man kann es wohl als besondere Herausforderung bezeichnen, Product Owner im Konzern zu sein. Die Frage ist dann immer, wie viel Produktverantwortung habe ich überhaupt oder anders gesagt: mit wie vielen anderen Menschen muss ich mir diese Verantwortung teilen? Tim hat heute Daniel Dubbel von der DB Systel zu Gast, um dieses diese Fragestellungen zu besprechen. Daniel ist langjähriger und erfahrener Agile Coach bei der DB Systel, dem internen IT-Unternehmen im DB Konzern. Daniel ist dort eine Führungskraft und in der Rolle als Agility Master aktiv an der Organisationsentwicklung des Unternehmens beteiligt. Im Rahmen dieser Verantwortung hat er die DB Systel auch im sogenannten DACH30 Netzwerk vertreten, einem Zusammenschluss von 30 Konzernunternehmen aus Deutschland, Österreich und der Schweiz, die sich seit einigen Jahren viermal im Jahr regelmäßig treffen, um über Agilität in solch großen Unternehmen zu diskutieren. In diesem Zuge wurden auch Diskussionen zu agilen Rollen im Konzern geführt und in sogenannte "Mindeststandards für Unternehmensagilität" entwickelt. Da es hierbei natürlich auch um die Product Owner Verantwortlichkeit ging, fanden wir es besonders spannend, Daniel Dubbel als Gast für diese Folge einzuladen und mit ihm darüber zu sprechen, was für Product Owner im Konzern vielleicht besonders oder anders ist. Aber auch bzgl. DACH30 wollte Tim wissen: Was war die Motivation, solche expliziten Rollenbeschreibungen für Konzernagilität zu definieren? Und inwiefern unterscheidet sich die Product Owner Rolle, die in diesen Mindeststandards als "Value-Verantwortlicher" beschrieben wird, vom Product Owner, wie er im Scrum Guide definiert wird? Einen spannenden Ausflug machen die beiden auch noch zur Fragestelleung, wie Kunden und Nutzer im Konzernumfeld eingebunden werden können. Am Ende des Gesprächs gibt Daniel Dubbel auch noch seine ganz persönlichen Tipps für Product Owner im Konzern. Tim verweist im Gespräch u.a. auf das "Lean Coffee für Agilität in Versicherungen", einer freiwilligen, ehrenamtlichen Netzwerk-Initiative, von Mitarbeitenden aus Versicherungsunternehmen. Alle sechs Wochen treffen sich hier Angestellte aus Unternehmen der Versicherungsbranche in einem selbstorganisierten, geschützten Raum. Wer festangestellt in einem Versicherungsunternehmen arbeitet, kann sich in der LinkedIn-Gruppe anmelden und bekommt dort dann die Einladungen mit. Achtung: Berater und Vertriebler werden explizit nicht in die Gruppe aufgenommen! Hier der Link zur Gruppe " Lean Coffee Agilität in Versicherungen ". Die "Mindeststandards für Unternehmensagilität" von 30 börsennotierten Großunternehmen aus Deutschland, Österreich und der Schweiz sowie drei deutschen Beratungsunternehmen sind in folgendem Artikel von Daniel Dubbel sehr gut dokumentiert: https://www.inspectandadapt.de/agile-rollen-kompetenzen/ . Infos über das DACH30-Netzwerk gibt es unter dach30.net im Netz. Frühere Episoden unseres Podcasts passen gut zur aktuellen Folge: Product Ownership im Konzernumfeld mit Felix Stein Customer Journey Management im Konzern - ein Erfahrungsbericht mit Martin Sallge Wer weitere Fragen an Daniel Dubbel hat oder mit ihm in Kontakt treten möchte, erreicht ihn am Besten über sein LinkedIn-Profil oder über seine Webseite inspectandadapt.de . Welche Erfahrungen hast Du als Product Owner im Konzern bislang gesammelt? Wie lässt sich die Product Owner Verantwortung im Konzernumfeld leben? Falls du den einen oder anderen Aspekt deiner Insights oder Tipps & Tricks mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Oliver & Dominique im Gespräch In vielen der vorherigen Podcastfolgen haben wir immer wieder einzelne Verhaltensmuster von Product Owner*innen angesprochen, die wir als Produktwerker eher kritisch sehen. Daher war es an der Zeit, eine Episode zu veröffentlichen, in denen Dominique und Oliver einmal viele relevante Antipattern an einer Stelle zusammenfassen. So bekommst Du als PO die Chance, diese Antipattern mit Deinem Verhalten zu vergleichen und ggf. kritisch zu hinterfragen, ob Du an dem einen Muster arbeiten möchtest. Die beiden klären zuerst ihr Verständnis von Antipattern, unter denen sie Lösungsansätze verstehen, die ungünstig oder schädlich für den Erfolg der eigenen Produktentwicklung oder des eigenen Unternehmens sind. Dabei unterteilen Oliver und Dominique diese PO Antipattern in drei Bereiche: eigenes Verhalten, Zusammenarbeit mit den Developer bzw. Produktentwicklungsteam und Kommunikation mit den Stakeholdern. Wir üblich versuchen die beiden auch ganz konkrete Beispiele aus ihrer eigenen Erfahrung sowie Tipps und Tricks zu nennen, wie ich an mir als Product Owner:in arbeiten kann, um wirksamer in meiner Rolle zu werden. ANDERE PODCASTFOLGEN, AUF DIE VERWIESEN WIRD Nein sagen als Product Owner Dein Freund der Scrum Master Seine Stakeholder kennen und richtig analysieren Epic. Sinnvoll oder nicht?…
D
Die Produktwerker
Tilman Büttner im Gespräch mit Dominique Wer sich in der UX-Community bewegt, kam in den letzten Monaten nicht um das Thema UX-Writing herum. Durch den richtigen Text an der richtigen Stelle soll das Nutzererlebnis verbessert werden. Grund genug, dass wir mal einen tieferen Blick in das Thema werfen und uns auch fragen, wie Product Ownern, Product Managern und Product Leadern UX-Writing helfen kann, bessere Produkte zu entwickeln. In dieser Folge spricht Dominique mit Tilman Büttner ( https://www.linkedin.com/in/tilmanbuettner/) , Senior UX Writer der Modulr.Design GmbH und Mitglied des Arbeitskreises UX-Writing der German UPA ( https://germanupa.de/arbeitskreise/arbeitskreis-ux-writing) , dem Berufsverband der deutschen UX-Professionals. Tilman erklärt, was UX-Writing ist und wie es sich beispielsweise vom klassischen Texten unterscheidet. Dabei wird schnell klar, dass sich hierbei ein großes Potenzial für den Erfolg oder Misserfolg von Produkten ergibt. Das beliebteste Beispiel sind Darstellungen eines Produkts ohne seine textlischen Inhalte. Da versteht man schnell, dass Bilder alleine nicht ausreichen und das jedes Wort relevant sein kann. Daher sprechen die beiden auch darüber, wie man eigentlich gute Texte für das eigene Produkt schreibt. Beispielsweise ist die Tonalität wichtig. Dabei zeigt sich auch der klare Bezug zum Beispiel zur UX-Vision ( https://produktwerker.de/ux-vision/ ) und dem absichtsvollen Gestalten der User Experience. Aber wie immer gibt es einige Fehler, die vermieden werden können. Über diese spricht Tilman in der Folge ausführlich und gibt uns somit Tipps und Tricks, wie wir einerseit smit UX-Writern zusammenarbeiten sollten aber auch wie wir notfalls ohne UX-Writer wenigstens etwas bessere Texte verfassen können. Wer über diese Folge hinaus noch Unterstützung sucht, dem sei die kostenlose Einführung ins UX Writing vom "UX Writing Hub" ( https://course.uxwritinghub.com/free_course ) empfohlen. Auch der Blog auf derselben Website ist für Interessierte empfehlenswert. Ein paar weitere praktische Tipps gibt es darüber hinaus auf der Website der Nielsen Norman Group ( https://www.nngroup.com/articles/ux-writing-study-guide/) . In einer langen Serie aus Artikeln und Videos bereitet sie das Thema gut verständlich auf.…
D
Die Produktwerker
Dominique & Oliver im Gespräch Als Product Owner kann ich im Alleingang niemals erfolgreich sein. Ohne Team bist Du nichts! Grund genug, für Dominique und Oliver einmal auf die Bedeutung des Teams für Product Owner zu schauen. Die beiden diskutieren dabei sowohl über die Developer– als auch über die Stakeholder–Seite und geben wie immer eine ganze Reihe von Tipps und Tricks aus der eigenen Praxis. Natürlich ist es spannend, was der Scrum Guide zum Team sagt und welche Auswirkungen dies auf die Arbeit der Product Ownerin hat. Besondere Wichtigkeit kommt der Zusammenstellung des Teams und der Fähigkeiten / Skills der eigenen Teammitglieder zu. Hier motivieren Oliver & Dominique, sich als PO einzumischen und zu positionieren, damit wir im möglichst optimalen Kontext unterwegs sein können. Mit Unterstützung des Scrum Masters müssen wir uns alle weiterentwickeln. Dabei ist das Mindset der Teammitglieder von Bedeutung, die beiden empfehlen eher auf interessierte, lernwillige Allrounder mit einer besonderen Expertise zu setzen als auf Spezialisten.…
Sohrab Salimi im Gespräch mit Tim Die Transformation hin zum Product Operating Model ist das neue zentrale Thema von Marty Cagan seit diesem Sommer. Er hat es Ende Juli in London im Rahmen des TRANSFORMED Workshops vorgestellt. Unser heutiger Gesprächsgast Sohrab Salimi war vor Ort in London und tauscht sich dazu mit Tim Klein. Tim war seinerseits im letzten Jahr drei Tage im Coach-the-Coaches Retreat von und mit Marty Cagan und seinen Kollegen der svpg. Dort wurden die ersten Ansätze zum Product Operating Model auch schon angesprochen. Das ganze wird sich dann ab kommendem Frühjahr (vermutlich März 2024) im neuen Marty Cagan Buch "TRANSFORMED" nachlesen lassen. Von Sohrab, der ein sehr gern bei uns gesehener und somit wiederkehrender Gast bei uns im Podcast ist, können wir also quasi von echtem Insider-Wissen, zumindest aber mit Infos aus erster Hand, profitieren. Falls ihr Sohrab noch nicht kennt: Sohrab ist Gründer & CEO der Scrum Academy GmbH und seit fast zehn Jahren Certified Scrum Trainer® sowie Certified Agile Leadership Educator der Scrum Alliance, wo er bis Ende 2020 Mitglied des Board of Directors war. Wer noch mehr wissen möchte, hört sich am besten nochmal eine der weiteren Folgen mit ihm an: Sohrab Salimi in Folge 11: " Product Owner als Agile Leader " Sohrab Salimi in Folge 54: " Business- oder Nutzersicht: Welchen Blickwinkel sollte ein PO einnehmen? " (mit Markus Andrezak) Weitere passende Quellen zum Product Operating Model Vortrag von Marty Cagan " Moving to the product operating model " im Webinar der Product-Led Alliance Weitere Vorab-Infos zum kommenden Buch von Marty Cagan "TRANSFORMED" "10 takeaways from a day spent with 50 European product leaders talking about ‘Transforming to the Product Model’" - von Product Coach Nick Jemetta, den Tim letztes Jahr beim Coach-the-Coaches Event von Marty Cagan kennengelernt hat Agile Insights Interview von Sohrab Salimi im Gespräch mit Marty Cagan: Product Leadership Teresa Torres bei Product at Heart: Even You Can Do Continuous Discovery. Bringing the Discovery Habits to Every Organization Wenn du mit Sohrab Salimi direkt in Kontakt treten möchtest, folge ihm am Besten auf LinkedIn oder kontaktiere ihn über sein LinkedIn-Profil. Eine weitere Empfehlung ist seinen regelmäßigen LinkedIn-Newsletter zu folgen. Hier teilt es immer wieder (i.d.R. wöchentlich) tolle Leadership Tipps und Gedanken. Hast du bereits vom Product Operating Model gehört? Oder seid ihr anderweitig auf der Transformationsreise zu einem produktzentrierten Organisationsmodell? Falls du den einen oder anderen Aspekt deiner Erfahrungen oder Tipps & Tricks mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Tim & Dominique im Gespräch "Wie groß ist ein Epic?" oder "Ab wann ist eine User Story ein Epic?" - mindestens eine dieser beiden Fragen hören wir tatsächlich in quasi jedem Training, wenn es um die Arbeit mit User Stories oder Product Backlog Management geht. Offenbar besteht einiges an Unsicherheit rund um dieses Thema. Also haben sich Tim und Dominique das Thema "Epic" in dieser Episode mal vorgeknöpft. Sie klären nicht nur den Unterschied zu User Stories, sondern erzählen auch vom historischen Hintergrund des Begriffs. Die Frage lautet nämlich eigentlich viel eher: Warum gibt es keine Saga und Novel mehr? …zumindest in Jira haben es diese anderen Begriffe nicht geschafft. Tim folgt eher die These (von Mike Cohn): "eine Story ist eine Story, ist eine Story…" Demnach ist ein Epic nur ein Label oder Kunstbegriff für eine sehr große Story. Aber andersrum: Wenn wir Stories aufteilen bzw. splitten, entstehen daraus doch ja auch nur wieder Stories. Und selbst wenn diese nochmals geschnitten werden müssen, kommen doch wieder nur (kleinere) Stories dabei heraus. Warum wir "nach oben" denn dann so ein "mythischer" Begriff verwendet. Dominique nutzt hingegen gerne Epics und berichtet im Gespräch davon ausführlich. Auch ein Umgang mit Epics in Jira wird von ihm entsprechend erläutert. Besonders spannend dürfte sein, was er macht, wenn nicht alle User Stories eines Epics umgesetzt werden. Einig sind sich beide, dass ein Epic einen Wert liefern muss. Es sei der Hinweis erlaubt, dass es im Skalierungs-Framework SAFe explizit den Begriff Epic verwendet. Dort ist es eine "significant solution development initiative") und es werden Business Epics und Enabler Epics unterschieden. Eine weitergehende Erklärung gibt es hier . Tim und Dominique gehen in dieser Episode aber bewusst nicht näher auf den Epic-Begriff in SAFe ein, sondern konzentrieren sich auf die aus dem Extreme Programming (XP) stammende Herkunft des Begriffes. Lieber beleuchten die beiden nämlich, welche Vorteile, aber auch welche Herausforderungen in der Arbeit mir Epics gibt. Und es ist auch spannend zu diskutieren, was denn fehlen würde, wenn man ganz auf die Verwendung von Epics verzichten würde. Wie in unserem Format üblich schließt die Folge mit einigen Tipps & Tricks zu diesem Thema. Passende Podcast-Folgen zum Thema "Epic" Erfolgreich mit User Stories arbeiten User Story Splitting: Wie geht das "richtig"? Arten von Product-Backlog-Einträgen: Was gibt's neben User Stories noch? Feature Breakdown: schnell User Stories finden und grob schätzen Passende Themen in unserer Produktwerker Box: In der Produktwerker Box findest du zu den typischen Herausforderungen von Product Ownern von uns empfohlene Literatur, Artikel, Videos, Tools, Übungen etc. - ein Blick in folgende Themenbereiche lohnt sich im Kontext dieser Episode: Gute User Stories schreiben bzw. formulieren User Story Splitting: Anforderungen schneiden Wie sind deine Erfahrungen mit Epics? Hast du vielleicht eine andere Sicht oder arbeitest ganz anders mit Epics als wir berichtet haben? Vielleicht hast Du auch spezielle Tipps zum Umgang mit Epics in den diversen Tools: Jira, Azure DevOps (Team Foundation Server), Redmine, Trello, Asana, … Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Büşra Coşkuner im Gespräch mit Tim Eine Folge zum Impact Mapping war dringend überfällig! Über diese sehr starke Praktik im Produktmanagement spricht Tim Klein daher mit Büşra Coşkuner aus Zürich. Sie ist Product Management Coach und eine der absoluten Expertinnen zum Impact Mapping im deutschsprachigen Raum. Tim liebt ja bekanntlich eh quasi alle Mapping Techniken, weil sie durch die Visualisierung für so viel mehr Klarheit sorgen und Entscheidungen sowie Zusammenhänge explizit machen. Daher setzt er diese Methode auch schon viele Jahre selber ein. Büşra hat den Ansatz aber nochmal weiterentwickelt (Adjusted Impact Map) und ist sehr erfahren in ihrer Anwendung mit Produktteams. Die Praktik wurde insbesondere durch Gojko Adzic und sein (sehr dünnes) Buch "Impact Mapping: Making a big impact with software products and projects" bekannt. Viele weitere Erklärungen und Ressourcen findet ihr auf impactmapping.org. Impact Mapping klärt insbesondere die Frage, was wir versuchen bzw. umsetzen könnten, damit bestimmte Akteure ihr Verhalten in einer Art und Weise verändern, die eine (positive) Wirkung auf ein von uns verfolgtes Businessziel haben könnte. Gemeinsam sucht man also Zusammenhänge von "Why" - "Who" - "How" und "What" und visualisiert sie in einer Art Mindmap. Während die ursprüngliche Idee in dieser Reihenfolge erfolgt, schlägt Büşra Coşkuner vor, auch mal eine "Reverse Impact Map" auszuprobieren. Das Vorgehen erklärt sie in ihrem entsprechenden Blog-Artikel . Ein weiterer guter passender Artikel von ihr beleuchtet den Outcome-Fokus sowie den Zusammenhang zu OKR ( Outcome-focus with Impact Mapping ). Es lohnt sich übrigens sehr, ihrem Blog zu folgen! Wie im Gespräch von Büşra bereits angeboten, hat sie uns dankenswerter Weise auch ihre zwei Templates aus den Übungen ihres Trainings zur Verfügung gestellt: Template 1: Wenn man z.B. schon weiß, dass man etwa bestimmtes umsetzen möchte, wäre ein Aufbau für einen Mini-Pitch: In order to achieve [IMPACT], we want to help/make [ACTOR] to/with [OUTCOME] with/by [OUTPUT]. Our riskiest assumptions are [ASSUMPTION 1], [ASSUMPTION 2], [ASSUMPTION 3]. …und falls dieser Detail-Level erwünscht ist: We'll test our assumption with these experiments: [EXPERIMENT 1], [EXPERIMENT 2], …[EXPERIMENT n] Beispiel: In order to Grow Mobile Advertising, we want to make Super-fans with mobile devices to Come back more frequently with Push Updates about my favorite artists. Template 2: Wenn wir es noch nicht wissen, weil da ganz fette Annahmen dahinterstecken und wir mehr Daten brauchen: We believe that by [doing this output] --> Solution for [these people] --> Actor we'll achieve [This Outcome] --> Impact which we believe will lead to [this business result] --> Goal We'll know if we are right, when we achieve [quant. or qual. indicators or results]. We'll test our assumption with these experiments: [EXPERIMENT 1], [EXPERIMENT 2], … [EXPERIMENT n] Beispiel: We believe that by Pushing Updates about favorite artists for Super-fans with mobile devices we'll make them come back more frequently which we believe will lead to a growth in mobile advertising. Weitere Podcast-Folgen und Quellen, auf die Tim und Büşra im Laufe des Gesprächs hinweisen: Data-Fluent Product Manager (mit Büşra) Outcome Goals & Product Discovery (mit Tim Herbig) Evidence Based Management - eine empirische Suche nach Wert (mit Boris Steiner und Glenn Lamming) Post zum Opportunity Solution Trees von Teresa Torres Falls Du mit Büşra Kontakt aufnehmen oder ihr folgen möchtest, kannst Du Dich über ihr LinkedIn Profil mit ihr verbinden. Kanntest du Impact Mapping bereits vorher? Hast du eventuell selbst schon mal an einer solchen Mapping Session in Präsenz oder Remote teilgenommen? Falls du den einen oder anderen Aspekt deiner Erfahrungen oder Tipps & Tricks mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Felix Rink im Gespräch mit Oliver Felix Rink ist wie versprochen zum zweiten Mal Gast im Produktwerker Podcast. Er spricht mit Oliver über Flow Metriken und in wie weit diese für Produktmenschen hilfreich sein können. Nachdem die beiden vor einigen Wochen über Sinn und Unsinn von Vorhersagbarkeit in der Produktentwicklungen philosophiert haben, wird es in dieser Episode also wesentlich konkreter. Zu Beginn der Folge klären Oliver und Felix, was Flow überhaupt ist und welche Voraussetzungen erfüllt sein müssen, damit man Flow messen kann. Der Kanban Trainer bricht die Flow Metriken im Anschluss auf die vier wichtigsten Basis Metriken herunter. Besonders wertvoll für den eigenen Kontext sind Felix Ideen und Anregungen, in welchen Scrum Events und bei welchen Praktiken und Artefakten diese Flow Metrics die Verantwortlichkeit eines Product Owner unterstützen können. Im Detail geht es um das Sprint Planning und das Sprint Review, sowie die Arbeit mit dem Product Backlog. Wie gewohnt schließt die Podcastepisode mit Tipps und Tricks für deine tägliche Arbeit als PO ab. Felix empfiehlt in der Episode, Actionable Agile für Flow Metriken oder die Monte Calo Simulation einzusetzen. Actionable Agile - https://www.actionableagile.com Es gibt wie erwähnt auch Excel Alternativen. Felix empfiehlt zwei Templates: https://github.com/SkeltonThatcher/bizmetrics-book#example-spreadsheets https://www.focusedobjective.com/pages/free-spreadsheets-and-tools…
Dominique und Tim im Gespräch In dieser Folge referenzieren wir folgende Folgen: Produktmanager im Startup – ein Erfahrungsbericht ( https://produktwerker.de/produktmanager-im-startup/ ) Fähigkeiten sehr guter Product Owner ( https://produktwerker.de/fahigkeiten-eines-po/ ) Seine Stakeholder kennen und richtig analysieren ( https://produktwerker.de/stakeholder-analysieren/ ) Sei dein eigenes Produkt! ( https://produktwerker.de/sei-dein-eigenes-produkt/ )…
D
Die Produktwerker
Johannes Geske im Gespräch mit Tim Wie bitte? In nur wenigen Wochen von der Idee zur Marktreife eines Produkts? Wie soll das denn bitte gehen? Tim hat Johannes Geske als Gast dazu eingeladen, denn er hat als Product Owner im Kundenauftrag für eine weltweit aktives B2B Unternehmen gezeigt, wie sowas mit streng hypothesen-getriebenem Vorgehen gelingen kann. In nur drei Sprints wurde durch iterativ-inkrementelles Vorgehen im Zusammenspiel mit intensiver Product Discovery ein release-fähiges Produkt für rund 15.000 Kunden des Auftragnehmers geschafften. Das Scrum Team von Johannes Geske war allerdings zuvor schon komplett eingespielt und in der Zusammenarbeit entsprechend erfahren, so dass es hier keine Lernkurve der Teamentwicklung gab, sondern der komplette Fokus auf ein schnelles Lernen durch Feedback gelegt werden konnte. Johannes nennt solch ein Setup "Plug & Play Scrum Team". Konkret wurden durch das Team einige Hypothesen bereits während jedes Sprints durch Kundenbesuche und unmittelbares User-Feedback zum Produkt Inkrement verifiziert bzw. eben auch einige falsifiziert. Letzteres ist eigentlich besonders "schön", denn diese Ideen muss man dann ja auch gar nicht umsetzen und vermeidet Verschwendung. In seinem Erfahrungsbericht spricht Johannes Geske über die Learnings dieses Vorgehens, wie z.B. klare Problem-Fokussierung, wie Vertrauen beim Kunden für dieses Vorgehen erworben wurde sowie die Festpreis-Beauftragung je Sprint durch den Kunden, d.h. z.B. auch die Go/NoGo-Entscheidung nach jedem Sprint. Für alle, die sich Details in Ruhe durchlesen wollen, hat Amazing Outcomes eine vom Kunden freigegebene Case Study erstellt. Diese gibt's hier: https://amazing-outcomes.de/de/what-we-offer/plug-and-play-scrum-team-fuer-ihr-projekt Mehr über Johannes Geske und sein Team erfahrt ihr auf der Webseite von Amazing Outcomes: https://amazing-outcomes.de/ . Gerne freut er sich auch über den direkten Kontakt zu euch - am besten per Mail (hello@amazing-outcomes.de) oder LinkedIn, wo ihr ihm auch folgen solltet: https://linkedin.com/in/johannesgeske/ Passende Episoden aus unserem eigenen Podcast rund um dieses Thema sind: Agiler Festpreis – Chancen & Grenzen dieser Vertragsform Das Problem mit dem Minimal Viable Product Welche Erfahrung habt ihr schon mit streng hypothesengetriebener Entwicklung gemacht? Wie gelangt ihr von einer Idee zur Marktreife? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K…
Beate Radics im Gespräch mit Dominique Mehr über Beate erfahrt ihr auf ihrem LinkedIn-Profil .
Oliver und Tim im Gespräch Hast du schon einmal von "Organisatorischen Schulden" gehört? Wir nutzen den Begriff in Analogie zu "Technischen Schulden" und beziehen uns damit auf organisatorische "Abkürzungen", das (bewusste) Weglassen von Scrum Elementen oder einer Vernachlässigung agiler Ideen und Prinzipien in Organisationen, die langfristig zu Problemen und damit natürlich auch zu Kosten führen. In dieser Podcast-Episode beschäftigen sich Tim und Oliver mit diesem Thema und zeigen vor allem auf, wie organisatorische Schulden auch deinen Erfolg als Product Owner beeinflussen können. Als Product Owner oder agile Produktmanager bist du möglicherweise schon mit den Herausforderungen konfrontiert worden, die sich aus der Einführung von Scrum oder anderen agilen Methoden in deine Organisation ergeben können. Mal gibt es noch keinen Scrum Master, mal fehlt die Zeit für Reviews oder Retrospektiven. Oder du musst als Product Owner für drei oder vier Scrum Teams parallel wirken. Oliver und Tim erklären zunächst ihr Verständnis vom Begriff der "Organisatorische Schulden" und zeigen die Vorteile und Nachteile auf, wenn ich Organisationen im Rahmen der agilen Transformation oder bei der Einführung von Scrum in die organisatorische Schuld begeben. Denn, wenn man dies ganz bewusst macht, kann dies absolut Sinn machen - genau wie bewusst eigegangene "Technische Schulden", um ein Produkt oder Feature schneller an den Markt zu bekommen und mit ihm früher Outcome erzeugen zu können. Die beiden zeigen dann im Hauptteil eine ganze Reihe von Beispielen für organisatorische Schulden auf, die sie in ihrer Arbeit als agile Coaches und Berater erlebt haben. Dabei diskutieren sie, wie man sie erkennt und vor allem wie sie auf die Product Owner Rolle wirken. Natürlich gibt es aber auch wieder konkrete Tipps, wie du als Product Owner oder agiler Produktmanager mit organisatorischen Schulden umgehen kannst. Also, hör rein in die neueste Episode "Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner" und erfahre, wie du dich als PO von ihnen nicht aus der Erfolgsspur bringen lässt. Im Gespräch werden folgende ältere, aber immer noch wertvolle, Episoden aus unserem eigenen Podcast rund um dieses Thema erwähnt: Product Owner ohne Scrum Master – geht das? Technische Schulden und wie wir als Produkt Owner damit umgehen Dein Freund der Scrum Master Hast du dich schon mal bewusst mit dem Begriff der Organisatorischen Schulden beschäftigt? Wie geht ihr in eurer Organisation damit um - egal ob ihr das Phänomen so oder anders benennt? Wir freuen uns, wenn du eure Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K…
Oliver und Dominique im Gespräch Wie immer setzt sich der Inhalt dieser Folge in Beziehung zu anderem Wissen. Daher hier die Liste der Referenzen, die in dieser Folge genannt wurden: Crossing the chasm von Geoffrey Moore Das POEM ( https://productownership.de/poem/ ) von Oliver und Tim Die vier Wissensdomänen der Produktentwicklung ( https://www.designik.de/2018/08/die-vier-wissensdomaenen-der-produktentwicklung/ ) Folge über das Evidence Based Management ( https://produktwerker.de/evidence-based-management/ ) Folge übers "Nein Sagen" ( https://produktwerker.de/nein-sagen-als-product-owner/ )…
Bernadette von Wittern im Gespräch mit Oliver Wir sprechen in dem “Die Produktwerker” Podcast häufig über Digitalprodukte, da wir alle aus diesem Kontext kommen. Grund genug, mit Bernadette von Wittern einmal eine Expertin für Product Management für Hardwareprodukte einzuladen. Sie hat lange Jahre als Produktmanagerin in der Medizintechnik gearbeitet bevor sie 2020 mit ihrem Unternehmen Product Lounge den Schritt in die Selbständigkeit gewagt hat. Nachdem Bernadette einleitend ihr Verständnis von Produktmanagement geteilt hat, sprechen Oliver und Bernadette über die unterschiedlichen Aufgabenbereiche und Verantwortlichkeiten. Sie teilt dabei spannende Ergebnisse einer aktuellen Studie, die sie im Rahmen der Überarbeitung eines Produktmanagement Buches durchgeführt hat. Daraus kann man einen guten Überblick über das “state of the art” für Product Management für Hardwareprodukte bekommen: Welche Aufgaben haben Produktmanager wirklich? Was sind typische Herausforderungen im Joballtag? Was macht Produktmanager erfolgreich und persönlich zufrieden? Bernadette und Oliver schließen die Folge, indem sie auch auf Gehälter und die immer noch existierende Unterschiede zwischen Frauen und Männer blicken. Wie immer schließt die Folge mit Tipps und Tricks.…
Dominique und Oliver im Gespräch Viele Wege führen nach Rom… so heißt es ja ganz gern. Und auch zur Verantwortung als Product Owner gibt es unzählige Wege. In dieser Folge sprechen Dominique und Oliver über den Weg über die Verantwortung als Scrum Master, denn sicherlich gibt es den ein oder anderen Vor- und Nachteil, wenn man sich vorher in diese Rolle befunden hat. Ein ganz großer Vorteil ist natürlich, dass man sich schon lange mit Scrum und den verschiedenen Verantwortungen beschäftigt hat. Einem sind dann beispielsweise besonders die Vorteile von iterativer, inkrementeller Entwicklung eines Produkts bereits klar. Auch hat man meist schon viele Fertigkeiten und Erfahrungen beim Durchführen von Workshops gesammelt. Dafür wird man aber auch vor ein paar Herausforderungen stehen. Innerhalb einer Organisation ist ein Rollenwechsel manchmal nicht so leicht zu kommunizieren. Manche Menschen sehen einen noch in der alten Funktion. Gleichzeitig muss man aber in der neuen Rolle den Fokus auf das Produkt anstelle des Teams legen. Das Team wird nicht unwichtig aber der Fokus liegt nun auf der Wertschöpfung. Wenn dann jemand anderes (insbesondere jemand mit weniger Erfahrung) die Verantwortung als Scrum Master übernimmt, muss man sich bewusst zurückhalten und dem Scrum Master nicht ins Handwerk pfuschen. Die Zeit muss eher in den Aufbau von Fertigkeiten rund um Produktmanagementtechniken und Denkweisen liegen. Und wenn ihr denkt, man könne als Product Owner auch direkt die Verantwortung als Scrum Master übernehmen, dann empfehlen wir euch unsere Folge "Product Owner ohne Scrum Master" ( https://produktwerker.de/product-owner-ohne-scrum-master/) . Wir freuen uns immer über Feedback zu unseren Podcast-Episoden. Bist du selbst aus der Verantwortung als Scrum Master hin zum Thema Product Owner gegangen? Dann lass uns gerne an deinen Erfahrungen teilhaben. Gerne in den Kommentaren auf unserer Website ( https://www.produktwerker.de/vom-scrum-master-zum-product-owner/ ) oder auf LinkedIn ( https://www.linkedin.com/company/produktwerker/) . Vielen Dank!…
Indra Burkart im Gespräch mit Dominique Ohne User Research sind wir ständig im Blindflug. Wir müssen irgendwie herausfinden, wie Menschen mit unserem Produkt interagieren und können auf Grundlage von User Tests bessere Entscheidungen treffen. In dieser Folge unterhält sich Dominique mit Indra Burkart darüber, wie wir als Product Owner das Team bei User Tests einbinden können. User Tests sind ein wichtiger Teil des Designprozesses und helfen, das Benutzererlebnis (UX) zu verbessern. Durch sie können wir besser dafür sorgen, dass das Endprodukt den Bedürfnissen und Erwartungen der Menschen entspricht. Dieses Feedback von echten Menschen sorgt dafür, dass wir Nutzungsprobleme frühzeitig entdecken und unsere Designentscheidungen überprüfen können. In der Zukunft können wir anderes arbeiten, bessere Entscheidungen treffen oder sogar große Probleme bei der breiten Anwenderschaft verhinden; alles mit dem Ziel die Benutzerakzeptanz zu steigern. Die Einbindung des Teams (z.B. Developer, Designer, Business Analysten uvm.) in User Tests trägt dazu bei, dass das Team besser versteht, wie das Produkt genutzt wird und welche Probleme oder Schwierigkeiten dabei auftreten. Wenn solche Tests von anderen für das Team durchgeführt werden, gehen oft wichtige Erkenntnisse verloren und der Aufbau von Empathie ist erschwert. Bei Tests sollte ein Team aber nicht nur dabei sein, sondern aktiv mitwirken. Zum Beispiel kann das Team gemeinsam die Tests auswerten und auch direkt klären, welche Konsequenzen sie für ihre Arbeit zu ziehen sind. Wenn ihr mehr über Indra herausfinden wollt, schaut doch einmal auf ihr LinkedIn-Profil oder noch besser auf ihren YouTube-Kanal. In der Folge haben wir übrigens noch folgende Inhalte referenziert: Studie von Nielsen und Norman zur Anzahl notwendiger Testpersonen: https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ Wenn ihr mehr zum Thema Personas wissen wollt, empfehlen wir euch unsere Folge zu "Warum Personas für Product Owner wertvoll sind": https://produktwerker.de/warum-personas-fuer-product-owner-wertvoll-sind/ Und zum Abschluss noch hier das Video von Indra zum Thema Usability Tests: https://www.youtube.com/playlist?list=PLgZriansjqQ4Q7gHx3ZUMFcZ3haBFfDPv Wir freuen uns immer über Feedback zu unseren Podcast-Episoden. Welche Erfahrungen habt ihr beispielsweise mit dem Einbinden des Teams in User Tests gemacht? Gibt es Tipps, die ihr gerne mit anderen teilen wollt? Teilt gerne eure Sichtweise auf LinkedIn ( https://www.linkedin.com/company/produktwerker/) .…
Olivers Gedanken In dieser Podcastfolge wird Oliver seinen Frust über Stellenausschreibungen für Product Owner los. Denn gefühlt wurden noch nie mehr Product Owner gesucht, aber die Inhalte der Jobausschreibungen lassen auf ein bedenkliches Bild auf die Verantwortlichkeiten schließen. Oliver teilt seine Einschätzung anhand von vielen, konkreten Beispielen aus Stellenausschreibungen auf LinkedIn und Stepstone. Oft lassen auch die Jobtitel, wie Team Product Owner oder Technischer Product Owner auf den Aufgabenbereich und das Verständnis des ausschreibenden Unternehmens schließen. Natürlich gibt Oliver auch Tipps, auf welche Details ich als wechselwilliger PO achten sollte. Was sind Elemente von wirklich guten Stellenausschreibungen und welche Informationen zu dem potentiell neuen Product sollte ich im Vorstellungsgespräch einfordern. Die Folge schließt mit zahlreichen konkreten Tipps und Tricks ab.…
Lilith Brockhaus im Gespräch mit Tim Was sind No-Code Tools? Manchmal auch Low-Code Tools genannt. An welchen Stellen im Produktmanagement können Produktteams davon profitieren? Tim hat die No-Code Expertin Lilith Brockhaus von VisualMakers zu Gast und bespricht mit ihr die spannende Frage, ob und wie No-Code Tools Produktteams bei der Produktentwicklung helfen können. Dabei geht es zu Beginn natürlich erstmal um die Frage, was No-Code Tools (und auch Low-Code Tools) überhaupt sind. Ziemlich schnell macht Lilith klar, dass sie nicht glaubt, dass tatsächliche Programmierung bzw. coden damit obsolet wird. Vielmehr ergeben sich für Nicht-Programmierer neue Chancen, ihre Ideen schneller auszudrücken und mit Nutzern zu testen. Ihre These: es verändert sich hierdurch etwas in der Zusammenarbeit der Teams. Tim sieht zudem den großen Wert von No-Code Tools im Rahmen der Stakeholder-Kommunikation und eben grundsätzlich Ideen schnell und einfach mal ausprobieren zu können und halt auch mit weniger "Werkstolz-Schmerzen" das Gebaute wieder wegzuwerfen. Lilith gibt zudem eine ganze Reihe von Empfehlungen von No-Code Tools, die sie im Rahmen der Produktentwicklung einsetzen würde. softr.io levity.ai make.com bzw. zapier.com bubble.io airtable.com bzw. seatable.io bannerbear.com webflow.com Auf der VisualMakers Website gibt es zu einigen dieser Tools auch hilfreiche Tutorials und eine Tool-Übersicht . Zum Abschluss reden die beiden noch über die mögliche Datenschutz-Problematik und die Chancen und Grenzen der Skalierung beim Einsatz von No-Code bzw. Low-Code. Hierzu empfiehlt Lilith, sich die Erfahrung von FINN mal anzusehen: https://www.visualmakers.de/case-study/finn-x-make Um tiefer ins Thema No-Code rein zu kommen, bietet VisualMakers kostenlose No-Code Einsteiger Kurse an: https://www.visualmakers.de/no-code-online-training Tiefer rein, kommt ihr dann mit dem Rapid Prototyping Bootcamp: https://basics.visualmakers.de/rapid-prototyping Tim empfiehlt auch explizit, den VisualMakers Podcast und ist bereits großer Fan. Dort könnt ihr noch viel mehr von Lilith Brockhaus und Alex Sprogis und ihren tollen Gästen hören. Mehr über Lilith Brockhaus erfahrt ihr auf der VisualMakers Website: https://www.visualmakers.de/ . Gerne freut sie sich auch über den direkten Kontakt zu euch - am Besten per LinkedIn, wo ihr ihr auch folgen solltet: https://www.linkedin.com/in/lilith-brockhaus/ Passende Episoden aus unserem eigenen Podcast rund um dieses Thema sind: Wie hole ich User Feedback mit Kundeninterviews ein? Das Problem mit dem Minimal Viable Product Habt ihr schon Erfahrung beim Einsatz von No Code Tools bei euch im Produktteam? Und wenn ja, wie helfen sie euch und welche Tools habt ihr im Einsatz? Wir freuen uns, wenn du deine deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K…
Oliver und Tim im Gespräch Ist die Frage "Product Owner vs. Product Manager" überhaupt richtig gestellt? Ist das denn wirklich ein Gegeneinander? Ein Gegensatz bzw. Unterschied? In jedem Fall ist diese Frage eine der am Häufigsten und auch recht wild diskutierten Dinge im agilen Produktmanagement. Beim "Product Owner" ist die Herkunft und damit die Definition noch recht klar: das Ganze ist eine Verantwortlichkeit (früher: Rolle) aus dem Framework Scrum. Die Bezeichnung wird aber heute (nicht nur im Skalierungs-Framework SAFe) aber auch in vielen anderen Kontexten verwand - auch ohne einen Zusammenhang zu Scrum. Insofern schreiben auch viele Unternehmen Jobs als "Product Owner" aus - selbst wenn nicht nach Scrum gearbeitet wird. Oft inzwischen sogar, ohne dass überhaupt agil gearbeitet würde. Beim Produktmanager (Product Manager) ist die Sache hingegen noch wesentlich unschärfer. Seit 1927 bei Procter & Gamble (P&G) erstmals die Rolle des Product Managers zur Herstellung des Markterfolgs für die Seifen- und Pflegeserie "Camay" etabliert wurde, gibt es den Job von Produktmanagern. Und oft hat er mit Business Modellen, der Produktvision, Produktstrategie, Wettbewerbsanalysen, Kundenfeedback, der Steuerung eines Produkts oder einer Produktlinie im Hinblick auf dem Markterfolg sowie der Formulierung der Anforderungen für die Produktweiterentwicklung zu tun. Aber schon in Bezug auf die initiale Produktgestaltung, Produktentwicklung und vor allem die technische Produkterstellung scheiden sich die Geister: sind das die Aufgaben eines Product Owners oder sind es die eines Product Managers. Oft beginnen hier auch die Konfliktlinien und es heißt: "Product Owner vs. Product Manager"! Wer hat welche Entscheidungs- und Mitspracherechte"? Ist die eine der anderen Rolle untergeordnet? Und wenn ja - in wer wem? In der Praxis sehen wir hier die unterschiedlichsten Varianten. Und vieles entspringt Missverständnissen und einer unausgesprochenen bzw. ungeklärten Entscheidungsverantwortung. Die Produktwerker können und wollen mit dieser Episode die ewige Frage nicht ein für alle Mal lösen, aber wir wollen hier einen Beitrag zu einer qualifizierten und reflektierten Diskussion über die beiden Begriffe liefern. Dabei ist unsere Meinung recht klar: Product Manager ist ein Job im Productmanagement und Product Owner eine Verantwortlichkeit (früher sagte man Rolle) in Scrum. Bedeutet: ein Product Manager kann Product Owner sein. In diesem Sinne macht es z.B. auch viel Sinn, im Rahmen eines Produktmanager Karrierepfads "Junior Produktmanager" und "Senior Produktmanager" Jobs zu vergeben. Hingegeben machen die Bezeichnungen "Junior" und "Senior" im Kontext von Product Ownern u.E. wenig Sinn. Hier sollte besser über die Relevanz, Größe bzw. Komplexität des Produkts die Entwicklung der Product Owner Erfahrung dokumentiert werden. In der Episode verweisen Tim und Oliver u.a. auf diese früheren Podcast-Folgen: Scrum Product Owner vs. SAFe Product Owner - ein Missverständnis Product Operations - nur ein Hype oder Next Big Thing? Was weiß künstliche Intelligenz schon über Produktentwicklung? Ebenso beziehen sich die beiden auf folgende Quellen: Marty Cagan: Two in a Box PM (2022) sowie seine Vorgängerartikel von 2016 ( Product Manager vs. Product Owner Revisited ) bzw. 2011 ( Product Manager vs. Product Owner ) POEM: Product Ownership Evolution Model von Tim Klein und Oliver Winter Ganz viel Content zu Produktmanagement gibt's bei Mind the Product (inzwischen kostenfrei!) Übersicht der aktuellen Produktmanagement-Trainings der Produktwerker (u.a. Produktvision erstellen; Produktstrategie und Product Roadmaps entwickeln): https://produktwerker.de/lernen/ Wie ist deine Meinung zur Streitfrage "Product Owner vs. Product Manager"? Siehst du einen Unterschied und beides auch auf mehrere Personen verteilt? Wir freuen uns, wenn du deine Meinung und deine Erfahrungen aus der Praxis zu dieser oft gestellten Frage mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K…
Felix Stein im Gespräch mit Tim Ist Product Operations nur ein neuer Hype oder handelt es sich um das "Next Big Thing" im Bereich Produktmanagement? Tim hat für dieses Thema Felix Stein, Geschäftsführer der Agile Process GmbH, zu Gast. In dieser Episode besprechen die beiden, wie wichtig es ist, eine klare Definition von Product Operations zu haben und wie diese Definition das Verständnis und die Verwendung von Product Operations im Unternehmen verbessern kann. Felix & Tim beleuchten daher die verschiedenen Definitionen von Product Operations von bekannten Branchenexperten wie Marty Cagan, Melissa Perry und John Cutler. Marty Cagan kritisiert, dass der Begriff Product Operations oft für wenig hilfreiche Interpretationen im Bereich Produktmanagement verwendet wird und grenzt "Production Operations" von "Product Operations" ab. Marty bezieht sich positiv auf die Definition von The Force Multiplier Model, die er selbst prägt und die sich auch auf die Product Operations Definition von Melissa Perri bezieht. Tim und Felix diskutieren diese Definition und wie sie sich von den anderen Definitionen, wie The Reincarnated PMO Model, The Two-in-a-Box PM Model, The Delegated Product Leader Model, Production Operations Rebranding Model, The Product Marketing Manager Rebranding Model unterscheidet, die Marty kritisch beleuchtet. Spannend ist, dass Melissa Perri wird bald ein Buch zu Product Operations veröffentlichen. Detailliertere Informationen zu dem kommenden Buch findest du auf productoperations.com . Quellen & Links Felix Stein war schon mal als Gast in diesem Podcast. Thema der Folge 117 war damals „Product Ownership im Konzernumfeld“ Folgende Quellen werden im Gespräch zitiert: John Cutler (Post): https://cutlefish.substack.com/p/tbm-4552-what-is-productops Marty Cagan (Post): https://www.svpg.com/product-ops-overview/ Melissa Perri (kommendes Buch): https://www.productoperations.com/ Melissa Perri: Escaping The Build Trap…
Dominique & Oliver im Gespräch Wir werden immer wieder gefragt, ob bzw. welches Training wir für Product Owner empfehlen (können). Über die Unterschiede von offenen & Innhouse Trainings spricht daher in dieser Folge Dominique mit Oliver. Nach einer ersten Begriffseinordnung von offenen und Inhouse Training wenden sich die beide vor allem den Vorteilen der unterschiedlichen Trainingsarten zu. Da wir als Produktwerker sehr regelmäßig Inhouse-Trainings geben, können wir hierzu eine ganze Reihe von Argumenten und Rahmenbedingungen nennen, warum die diese Trainingsform für Organisationen mit mehreren Product Owner sehr sinnvoll ist. Offene Trainings ermöglichen Teilnehmenden vor allem, dass sie sich mit Product Owner aus ganz anderen Branchen und Kontexten vernetzen können. So steigen die Chancen, im Training und den Gruppenarbeiten voneinander zu lernen und sich auch über das Training hinaus auszutauschen. Denn für die eigene Lernreise ist es unserer Meinung nach extrem wertvoll, nicht nur im eigenen Kontext zu denken, sondern den Blick über den Tellerrand zu wagen. Wie immer schließen Dominique und Oliver die Episode mit praktischen Tipps und Tricks ab. Offene Trainnings von den Produktwerkern http://produktwerker.de/lernen Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (mit Terminen für unsere kostenfreien Events) -> https://bit.ly/3Why63K…
Christoph Specht im Gespräch mit Dominique Jedes Produkt hat seine ganz eigenen Herausforderungen. Als Product Owner versuchen wir in unterschiedlicher Art und Weise damit umzugehen. In dieser Folge unterhält sich Dominique mit Christoph Specht, einem der Product Owner von JOYclub, über seine persönlichen Erfahrungen. JOYclub ist ein Onlineportal, auf dem sich erwachsene Menschen rund um das Thema Sexualität austauschen und miteinander verbinden können. Christoph spricht darüber, wie bei JOYclub die Verantwortung als Product Owner aufgeteilt ist und welche Herausforderungen er mit seinem Teil hat. Zwei interessante Herausforderung sind auf jeden Fall die Thematik des Portals und die Größe. Das Thema des Portals macht Tracking und Datenerhebung im Allgemeinen problematisch, da sich die Menschen bei der Nutzung des Portals auf eine gewisse Vertraulichkeit verlassen. Viele Inhalte auf dem Portal sind sehr privat und persönlich und die Menschen sollen das Gefühl haben, dass ihre Daten sicher und geschützt sind. Eine große Verantwortung für das Team. Die zweite besondere Herausforderung sind die mehr als einer Million Menschen, die an einem durchschnittlichen Tag aktiv sind. Eine stabile und belastbare Infrastruktur ist daher von elementarer Bedeutung. Auch werden viele verschiedene Endgeräte verwendet, die dem entsprechend unterstützt werden sollten. Christoph ist unter Anderem für den Medienupload verantwortlich. Gerade der Umgang mit Medieninhalten wie Bilder und Videos ist mit Vorsicht und Voraussicht zu handhaben. Christoph erzählt vom Aufwand hier den Menschen ein gutes Erlebnis zu bieten und gleichzeitig verantwortungsvoll zu handeln. Er erzählt aber auch, was er bereits aus der Übernahme der Produktverantwortung bei JOYclub gelernt hat und was er auch in Zukunft beibehalten wird. Wenn du auch bei deinen Produkten von spannenden Herausforderungen berichten kannst, freuen wir uns, wenn du uns an deinen Erfahrungen in einem Kommentar hier oder auf unserer Produktwerker LinkedIn-Seite ( https://www.linkedin.com/company/produktwerker ) teilhaben lässt. In Zukunft werden wir immer wieder von besonderen Produkten und mit ihren Herausforderungen berichten.…
ChatGPT im Gespräch mit Tim - ein echtes Experiment Künstliche Intelligenz ist in aller Munde und vor allem wird seit ein paar Wochen über das System ChatGPT von OpenAI diskutiert. Man kann diese KI auch selber ausprobieren, d.h. ihr Fragen stellen und erhält Antworten. Spannend ist, dass auch Nachfragen möglich sind, so dass eine "richtige" Konversation mit dem System stattfinden kann. Genau das haben wir in Bezug auf Produktentwicklung getan. Tim hat also mit dem System gechattet und ist mit der simplen Frage "Was ist ein Product Owner?" eingestiegen und hat sich auch den Unterschied zwischen einem Product Owner und einem Produktmanager von ChatGPT erklären lassen. Die Antworten von ChatGPT haben wir dann noch vom professionellen System NaturalReader vorlesen lassen. Auch dieses Vorlese-Ergebnis der Texte von ChatGPT ist an sich schon erstaunlich! Im Interview hat uns weiterhin interessiert, ob ChatGPT denn einen Product Owner hat und wie die Anforderungen an eine KI erhoben werden. Auch die Diskussion über Personas und die Nutzererwartungen an eine künstliche Intelligenz wie ChatGPT ist interessant. Zum Thema Personas haben wir schon mal sehr früh in diesem Podcast eine gute und tiefergehende Episode gemacht (Folge 18: "Warum Personas für Product Owner wertvoll sind" ). Ein Abgleich der Aussagen von ChatGPT mit der Produktwerker-Sicht auf das Thema lohnt sich daher auch mal. In dieser aktuellen Folge erklärt uns die KI auch einiges zur Entwicklung von ChatGPT. Spannend ist, dass dies den Antworten zu Folge auch mit Scrum erfolgt. Beim Rollenverständnis bzgl. Scum Master steigt Tim dann doch nochmal mit kritischen Nachfragen ein, denn die Scrum Master Aufgabe als "er leitet das Team" zu beschreiben, können wir so nicht unterschreiben. Aber die Antworten zur Frage, wie ein Scrum Master dem Product Owner (PO) helfen kann, sind schon gar nicht so schlecht. Zum Anschluss löchert Tim die künstliche Intelligenz mit der Frage: "Wie wird man ein guter Product Owner?" und die Antworten überraschten uns hier echt positiv. Hast du selber schon mit ChatGPT gesammelt oder sogar künstliche Intelligenz in eurem Produkt eingesetzt? Wir freuen uns, wenn du deine Meinung zu KI und deine Einschätzung für KI in der Produktentwicklung mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite . Den kompletten Wortlaut der Fragen und was die künstliche Intelligenz geantwortet hat, könnt ihr hier als Transkript nachlesen . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K…
Tim und Dominique im Gespräch In der Produktentwicklung spielen Kreativitätstechniken eine essenzielle Rolle. Sie dienen dazu, innovative Ideen zu generieren und den Entwicklungsprozess auf neue Bahnen zu lenken. In dieser Folge sprechen Tim und Dominique darüber, wie Kreativitätstechniken innerhalb der agilen Propduktentwicklung beispielsweise mit Scrum eingesetzt werden können. Viele setzen auf das altbewährte Brainstorming, aber es zeigt sich oft, dass diese Methode ihre Grenzen hat. Eines der Hauptprobleme liegt in der sozialen Erwünschtheit, die oft die Qualität der generierten Ideen beeinträchtigt. Brainstorming, führt regelmäßig dazu, dass Teilnehmende sich selbst zensieren oder Ideen aus Angst vor Ablehnung zurückhalten. Hier setzt das Brainwriting an, eine Alternative, die in diesem Kontext häufig als hilfreicher erachtet wird. Durch die Möglichkeit, Ideen schriftlich zu notieren, wird der soziale Druck reduziert. Alle Teilnehmenden können ihre eigenen Gedanken ohne Hemmungen aufschreiben, was zu einer größeren Bandbreite kreativer Ansätze führt. Ein weiterer Ansatz, der sich bewährt hat, ist die 635-Methode. Hierbei formulieren sechs Teilnehmende jeweils drei Ideen in fünf Minuten. Diese Ideen werden dann an die nächsten sechs Teilnehmenden weitergereicht, die darauf aufbauend neue Ideen generieren. Durch diese iterative Vorgehensweise entstehen in kurzer Zeit eine Vielzahl an Ideen, ohne dass der Einfluss sozialer Faktoren die Kreativität einschränkt. Da an der Produktentwicklung aber viele Köpfe beteiligt sind, bieten sich auch Techniken an, bei denen Menschen jeweils die gleiche Denkperspektive einnehmen. Beispielsweise haben sich Edward de Bonos Denkhüte als nützliches Instrument erwiesen. Diese metaphorischen Hüte repräsentieren verschiedene Denkrichtungen, die in der Gruppe durchgespielt werden können. Jeder Hut steht für eine andere Sichtweise: neutral, emotional, optimistisch, kritisch, kreativ und strukturiert. Indem die Teilnehmenden bewusst in diese verschiedenen Rollen schlüpfen, entsteht eine facettenreiche Betrachtung des Problems, die zu vielseitigen Lösungsansätzen führen kann. Dominique empfiehlt hier aber, dass alle Teilnehmenden immer die gleiche Perspektive einnehmen und nicht einjeder einen anderen Hut zur gleichen Zeit trägt. Eine weitere Methode, die sich bewährt hat, ist die Walt-Disney-Methode. Sie nutzt die Rollen des Träumers, Realisten und Kritikers, um eine Idee aus unterschiedlichen Blickwinkeln zu betrachten. Dadurch werden sowohl visionäre Ansätze als auch praktische Umsetzbarkeit beleuchtet, was zu ausgewogeneren und umsetzungsfähigen Ideen führen kann. -- Empfehlungen -- Wir möchten euch an dieser Stelle das Buch "How to have creative ideas" (ISBN 978-0-09-191048-8) von Edward de Bono empfehlen. Als persönliche Empfehlung von Dominique hier noch ein hervoragender Vortrag von John Cleese zum Thema Kreativität im Management: https://www.youtube.com/watch?v=Pb5oIIPO62g&ab_channel=VideoArts Passend zum Thema Kreativität hier ein paar weitere Folgen: Als Product Owner im Sprint Review ( https://produktwerker.de/als-product-owner-im-sprint-review/ ) Mit Storytelling andere von Deinen Produktideen überzeugen ( https://produktwerker.de/storytelling-fuer-product-owner/ ) Visual Leadership für Product Owner ( https://produktwerker.de/visual-leadership-product-owner/ )…
Rainer Gibbert im Gespräch mit Dominique Im Verlauf des Produktlebenszyklus müssen wir immer wieder Teile des Produkts verändern, aktualisieren oder an neue Erkenntnisse anpassen. Dies ist notwendig, um auch in Zukunft den Mehrwert unseres Produkts zu erhalten oder vielleicht sogar noch mehr Wert zu schaffen. Auf der anderen Seite haben Menschen, die unser Produkt schon länger nutzen, Zeit investiert, um die Bedienung zu erlernen. Jede Veränderung am Produkt bedeutet daher einen neuen Lernaufwand. Verständlicherweise lehnen Menschen Veränderungen ab, wenn sie den Nutzen nicht erkennen, nicht verstehen oder zumindest nicht nachvollziehen können. In dieser Folge spricht Dominique mit Rainer Gibbert, Leiter der Produktentwicklung bei der Star Finanz GmbH. Rainer hielt auf der Workings Products 2023 einen Vortrag zu diesem Thema. Immerhin ist er momentan für ein Produkt verantwortlich, das bereits seit 25 Jahren existiert. Viele Menschen haben sich an die Benutzung gewöhnt. Rainer diskutiert darüber, wie man damit umgehen kann, wenn Produktänderungen abgelehnt werden, und er erläutert, wie man diese Änderungen erfolgreich einführen kann. Er teilt mit, welche Vorbereitungen getroffen werden müssen, damit möglichst viele Menschen auf die neuen Funktionen, Änderungen und allgemeinen Anpassungen umsteigen. Wenn ihr nach dem Podcast noch einige Erkenntnisse nachlesen möchtet, empfehlen wir euch Rainers Artikel auf https://www.produktbezogen.de/produktaenderungen-warum-nutzer-sie-hassen/ . Weitere Informationen zu Rainer findet ihr auch auf seinem LinkedIn-Profil unter: https://www.linkedin.com/in/rainergibbert/ Wenn ihr eigene Erfahrungen zu dem Thema gesammelt habt, lasst es uns gerne auf LinkedIn oder auf dem Blogbeitrag zu dieser Folge wissen. Wir freuen uns auf eure Erfahrungen.…
Tim & Dominique im Gespräch Ist ein Proxy Product Owner sinnvoll? Wann und warum kann es diese Rolle geben? Wie kann man dieses Anti-Pattern überwinden oder im Zweifel auch damit umgehen? Zunächst mal erklären Tim und Dominique, was ein Proxy Product Owner ist bzw. was dies bedeutet. Auch die vielfältigen Gründe weshalb eine solche Rolle in bestimmten Situationen anzutreffen ist, werden erläutert. Besonders oft, sieht man eine solche Aufstellung, wenn das Scrum Team von einem Dienstleister gestellt wird, die Product Ownerin aber vom Auftraggeber gestellt wird. Letztlich ist der Einsatz einer Proxy Product Owner Rolle jedoch ein Anti-Pattern in Scrum. Insofern diskutieren die beiden, zu welchen Problemen es in der agilen Produktentwicklung durch solch eine Konstellation kommen kann. Spannend sind dann die Empfehlungen von Dominique und Tim, wie die Situation überwunden werden kann, also wie man diese "organisatorische Schuld" und somit die Proxy Product Owner Rolle wieder loswerden kann. Letztlich ist der Einsatz eines Proxy-PO auch recht nah dran an der Frage, ob und wie eine Arbeit mit zwei Product Ownern in einem Team möglich ist - dies war das Thema der letzten Folge. Im Zweifel also auch hier nochmal reinhören. Manchmal mag es aber auch Situationen geben, in denen - zumindest für einen bestimmten Zeitraum - mit dieser Rolle gelebt werden muss. Auch hierfür geben die beiden Empfehlungen ab, wie man dies möglichst gut meistern kann. Das Gespräch endet wie gewohnt mit Tipps & Tricks im Umgang mit der Herausforderung "Proxy Product Owner". Diese Podcast-Episoden passen zum Thema bzw. wurden erwähnt in dieser Folge erwähnt: Den Wert des Produktes maximieren Ein Scrum Team, zwei Product Owner. Geht das? Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner Der Product Owner aus Sicht eines Dienstleisters Zusammenarbeit mit dem externen Team eines Dienstleisters Warst du auch schon mal als Proxy-PO im Einsatz oder hast eine solche Situation in einem Team erlebt? Was war der Grund, dass dort ein Product Owner Proxy eingesetzt wurde? Und welche Erfahrung habt ihr dabei gemacht? Vielleicht hast du noch weitere gute Tipps, wie der Einsatz einer solchen Rolle sinnvoll und wertstiftend gelingen kann. Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Dominique & Tim im Gespräch Es gibt Situationen, in denen eine Organisation sich entscheidet, zwei Product Owner einem Scrum Team zuzuordnen. Also zwei Menschen sollen sich diese Verantwortlichkeit teilen: gemeinsam das Product Backlog managen, gemeinsam mit dem Scrum Team die Scrum Events durchführen usw. - auch wenn der Scrum Guide das definitiv anders beschreibt: Ein Team sollte genau eine Product Ownerin ("The Product Owner is one person, not a committee.") und ein Product Backlog haben. Aber in der gelebten Realität sieht man das schon mal anders. Wie kommt es dazu und geht das denn überhaupt? Tim und Dominique nennen in dieser Podcast-Folge die Gründe, wegen derer sich Organisationen für mehr als eine Product Ownerin entscheiden. Anschließen diskutieren sie die Risiken und Schwächen einer solchen Situation - insbesondere vor dem Hintergrund ihrer eigenen Erfahrungen mit solchen Konstellationen. Tim berichtet z.B. von einem Versuch, vier PO für ein Team zu installieren. Der Versuch scheiterte allerdings ziemlich schnell. Natürlich zeigen die beiden auch Lösungsansätze auf, um die Situation zu überwinden und diese "organisatorische Schuld" abzubauen. Wie kann es gelingen, das ganze auf nur einen Product Owner zu reduzieren? Abschließend besprechen die beiden aber auch, was geschehen müsste oder gegeben sein muss, um (zur Not) auch mit mehr als einem PO zu arbeiten. Diese Podcast-Episoden passen zum Thema bzw. wurden erwähnt: Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner Product Owner in Teilzeit Wie die Produktvision hilft, Product Ownern eine Richtung zu geben Warum scheint die Product Owner Rolle so schwer zu sein? (Gast: Markus Andrezak) Hast du das auch schon mal erlebt: zwei PO in einem Scrum Team? Was war der Grund, dass ihr euch so aufgestellt habt? Und welche Erfahrung habt ihr dabei gemacht? Vielleicht hast du noch gute Tipps, wie eine solche Konstellation gelingen kann. Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Laura Marwede & Dominique im Gespräch Wenn wir mit mehreren Teams an einem umfangreichen Projekt arbeiten, stellt sich oft auch im Design die Frage nach einer systematischen Vorgehensweise. Eine strukturierte Möglichkeit hierfür ist die Implementierung eines Designsystems. In dieser Folge wollen wir untersuchen, wann sich ein Designsystem in der Produktentwicklung lohnt und vor allem aus der Sicht der Product Owner beantworten. Dafür haben wir Laura Marwede eingeladen, Head of UX & Strategy bei TEAM23 , die sich mit ihrem Team bereits seit geraumer Zeit mit diesem Thema beschäftigt. Sie ist somit die ideale Person, um Dominique in dieser Episode Rede und Antwort zu stehen. Der potenzielle Mehrwert von Designsystemen liegt darin, dass sie einen konsistenten und strukturierten Ansatz für die Gestaltung und Entwicklung von Produkten bieten. Sie bestehen aus einer Sammlung von Komponenten, Stilen, Richtlinien und Prinzipien, die als Grundlage für das gesamte Design einer Anwendung oder eines Produkts dienen. Designsysteme fördern die Konsistenz und Einheitlichkeit in der Produktentwicklung. Durch die Verwendung vordefinierter Komponenten und insbesondere Stile können wir als Product Owner sicherstellen, dass das Erscheinungsbild und die Benutzererfahrung unserer Produkte einheitlich sind. Zudem können Designsysteme den Entwicklungsprozess beschleunigen, da wir nicht jedes Mal von Grund auf neu beginnen müssen. Ein Großteil der Gestaltungsentscheidungen ist bereits getroffen, was Zeit und Ressourcen spart. Es gibt jedoch auch potenzielle Nachteile bei der Verwendung von Designsystemen. Insbesondere der anfängliche Aufwand für die Erstellung eines Designsystems sollte nicht unterschätzt werden. Es erfordert Zeit und Ressourcen, um die richtigen Komponenten und Stile zu definieren und das Designsystem aufzubauen. Wenn dann jedoch immer wieder Diskussionen über das Design entstehen, wird der eigentliche Vorteil eines Designsystems nicht realisiert. Wann sollten wir als Product Owner also Designsysteme nutzen? Die Antwort ist: Es kommt drauf an. Wenn ein Produktteam wächst und das Produkt selbst eine gewisse Größe erreicht hat, kann die Einführung eines Designsystems die Zusammenarbeit erleichtern und die Konsistenz sicherstellen. Es wird dann zu einem nützlichen Werkzeug für die Produktgestaltende.…
Tim und Oliver im Gespräch Findet euer Sprint Review ohne Stakeholder statt? Oder kommen sie nur sporadisch? Tatsächlich ist das ein häufiges Problem in der Praxis und führt in der Arbeit mit Scrum zu ernsthaften Problemen. Tim und Oliver besprechen zunächst die Gründe, warum diese Situation eintreten kann. Danach diskutieren sie, welche Effekte das Fehlen von Stakeholdern im Sprint Review auf den Erfolg der agilen Produktentwicklung haben kann. Natürlich sind die Ideen und Vorschläge der beiden, wie man die Situation ändern kann, besonders spannend. Wie kann es gelingen, dass (wieder) mehr Stakeholder regelmäßig beim Sprint Review dabei sind und aktiv ihr wertschätzendes und konstruktives Feedback einbringen? Wie kann man es dem Umfeld bewusst machen, dass es wichtig ist, zu kommen und Feedback auf den aktuellen Stand der Entwicklung zu geben. Dabei ist auch wichtig, den Stakeholdern auch mit Respekt auf Augenhöhe zu begegnen und ihnen explizit zu sagen, wenn nichts Wesentliches für ihren Bereich in diesem Sprint dem Inkrement hinzugefügt wurde. Aber auch für den Fall, dass das alles nicht hilft und am Ende dann doch das Sprint Review ohne Stakeholder stattfinden muss, hauen die beiden noch einige, z.T. sehr kreative, Tipps raus. Diese Podcast-Episoden passen zum Thema "Sprint Review ohne Stakeholder" bzw. wurden erwähnt: Als Product Owner im Sprint Review Seine Stakeholder kennen und richtig analysieren Umgang mit schwierigen Stakeholdern Stakeholder Community Wer nimmt User Stories ab? Dein Freund der Scrum Master Warum scheint die Product Owner Rolle so schwer zu sein? (Gast: Markus Andrezak) Nutze Story Mapping, um mit Stakeholdern über Outcome zu sprechen Hast du auch das Problem, dass eure Stakeholder nicht zum Sprint Review kommen? Wie geht ihr damit um und welche guten Tipps habt ihr noch für uns und alle anderen Product Owner? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Felix Rink im Gespräch mit Oliver Die Frage nach einem konkreten Liefertermin für ein bestimmtes Feature begegnet uns als Product Owner immer und immer wieder. Aber wie steht es eigentlich generell mit einer Vorhersagbarkeit in der agilen Produktentwicklung? Dazu sprechen Oliver und Felix Rink, Kanban Coach und Trainer bei ProKanban.org. Die mit Augenzwinkern gemeinte Aussage "Wann ist das Feature fertig? Keine Ahnung, wir sind ja agil!" hat aber durchaus einen ernsten Hintergrund. Denn nach subjektivem Gefühl der beiden findet man eine solche Einstellung durchaus häufiger in der Praxis. Und manchmal kann man den Eindruck gewinnen, dass die agile Community sich generell mit Vorhersagbarkeit in komplexen Umfeldern schwer tut. Felix Rink erklärt, warum er es trotzdem wichtig findet, dass gerade ein Product Owner in der Lage sein sollte, eine verständliche Aussage auf Fragen nach Lieferterminen von Features geben zu können. Anschließend klären Oliver Winter und Felix Rink Hintergründe, worin das Problem liegt, wenn Dinge einfach nun mal so lange dauern wie sie dauern. Und natürlich hat Felix auch eine Lösungsidee mitgebracht. Sich durch Messungen und Analysen Transparenz über die eigene Leistungsfähigkeit zu schaffen, wird auch bei der Vorhersagbarkeit unterstützen. Dabei können bestimmte Flow Metriken hilfreich sein. Wie immer endet die Podcastfolge mit konkreten Tipps und Tricks. In der Episode erwähnte Podcast-Folgen • Assumption Mapping • Kennt Kanban Product Owner? Um mit Felix Rink Kontakt aufzunehmen, um ggf. weitere Fragen zu klären, erreicht man ihn am einfachsten über sein LinkedIn-Profil . Welche Erfahrung hast Du mit dem Thema dieser Podcastfolge gemacht? Wie gehst Du mit Nachfragen zu konkreten Lieferterminen von Seiten der Stakeholder um? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
Oliver & Dominique im Gespräch Fast schon nur am Rande empfehlen wir euch auch die Folge zu "Sei dein eigenes Produkt!", in der Dominique von seinem Weiterentwicklungsansatz für Product Owner spricht. -> https://produktwerker.de/sei-dein-eigenes-produkt/ Als weiterführende Literatur können wir übrigens das Buch "Überzeugt!" von Jack Nasher empfehlen. Hier finden sich viele hilfreiche Hinweise und Tipps dazu, wie man im Allgemeinen kompetenter auftritt. -> https://jacknasher.com/publikationen/…
Jürgen Meurer im Gespräch mit Tim Was hat Event Storming mit dem Bullshit-Asymmetrie-Prinzip (auch bekannt als "Brandolinis Gesetz") zu tun? Diese und noch viel wichtigere Fragen, besprechen wir in dieser Podcast-Folge mit Jürgen Meurer. Event Storming ist eine Praktik, die ursprünglich aus dem Domain Driven Design (DDD) stammt. Die Erfindung der Methode wird Alberto Brandolini zugeschrieben. Ja genau - der mit dem gleichnamigen Gesetz: „Das Widerlegen von Schwachsinn erfordert eine Größenordnung mehr an Energie als dessen Produktion.“ Zurück zum Thema: Event Storming ist ein (Groß)Gruppenformat, um das verteilte Wissen über eine fachlich-technische Domäne in einem Workshop explizit zu machen und so ein "gemeinsam geteiltes mentales Modell" zu entwickeln. Kurz: alle die dabei waren kapieren den Gesamtzusammenhang der Fragestellung plötzlich viel besser. Gerade im Kontext komplexer Produktentwicklung eignet sich diese Methode somit sehr gut, ein gemeinsames Verständnis zu schaffen. Sie kann damit eine tolle Grundlage für Story Mapping oder Customer Journey Mapping bieten - aber auch für die Erstellung klassischer Projekt Strukturpläne. Du kannst Event Storming sowohl für bestehende Produkte anwenden, als auch in der Entwicklung komplett neuer Produkte und Services einsetzen. Jürgen Meurer, setzt diese Methode bereits seit vielen Jahren erfolgreich bei seinen verschiedenen Arbeitgebern an. Inzwischen ist Jürgen als Agile Coach aktiv, hat aber auch lange als Product Owner und Scrum Master gearbeitet. Damit ist er übrigens auch ein interessantes Beispiel für den Weg, sich vom Product Owner zum Scrum Master bzw. Agile Coach zu entwickeln. Seine letzten Stationen waren Studitemps, Freeyou, AXA und nun SHOP APOTHEKE bzw. Redcare Pharmacy . Quellen und Links zum Event Storming Jürgen Meurer empfiehlt die folgenden Quellen, um mehr über Event Storming zu lernen: zentrale Webseite zum Thema: eventstorming.com Buch von Alberto Brandolini (online verfügbar): Introducing EventStorming - An act of Deliberate Collective Learning Brandolinis Gesetz , auch Bullshit-Asymmetrie-Prinzip genannt Weitere Themen zu bestimmten Podcast-Folgen, auf die Tim im Laufe des Gesprächs hinweist: Nutze Story Mapping, um mit Stakeholdern über Outcome zu sprechen Mit Customer Journey Maps arbeiten Jürgen Meurer freut sich über den Kontakt zu euch. Für weitere Fragen rund um das Thema und zu seinen Erfahrungen erreicht ihr ihn am besten auf seinem LinkedIn-Profil . Kanntest du Event Storming bereits vorher? Hast du eventuell selbst schon mal an einer solchen Session teilgenommen? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
D
Die Produktwerker
Tim & Oliver im Gespräch Viel zu oft hören wir als Product Owner von Stakeholdern den Satz: "Wir wissen was die Nutzer brauchen". Unsicherheiten, die es in jeder Produktentwicklung gibt, finden nach Sicht von Tim & Oliver viel zu wenig Raum in der täglichen Arbeit und Diskussionen. Grund genug, dass sich die beiden in dieser Podcastfolge mit dem Thema Assumption Mapping beschäftigen. Eine Option, auf die pauschale Aussage der Stakeholder zu reagieren, ist es, eine gedankliche Wette anzubieten - "OK, willst Du wetten?" Was bist Du bereit zu wetten?". Denn ein Problem ist, dass wir viel zu oft in unser Problemverständnis und unsere Lösungsideen verliebt sind. Dazu kommt dann auch der eine oder andere Bias. Haben wir es als Product Owner einmal geschafft, Lust und Verständnis für ein vermehrt experimentelles Vorgehen in unserem Umfeld geschaffen, stellt sich die Frage, mit welcher Annahme wir starten sollten. Daher erklärt Tim in der Folge das Assumption Mapping, welches uns bei der Herausforderung helfen kann. Die von David J. Bland entwickelte Praktik klassifiziert unsere Hypothesen in die Dimensionen Evidenz & Business-Kritikalität. Ziel ist es, in den Modus "Learn - Build - Measure" zu kommen. Tim und Oliver erläutern, wen wir als Product Owner mit in die Diskussionen rund um das Assumption Mapping einbeziehen sollten. Und welche Vorteile wir als PO daraus ziehen. Wir immer schließt die Folge mit einigen ganz konkreten Tipps & Tricks ab. Weitere Quellen & Links Assumption Mapping als Teil des Google Design Sprints Webseite von David J. Bland Confidence Meter von Itamar Gilad Product Management in Practice - Matt LeMay Continuous Product Discovery Habits - Teresa Torres Testing Business Ideas - David Bland & Alexander Osterwalder…
Silke Kanes im Gespräch mit Tim Wie blickt ein Vorstand auf die Verantwortlichkeit eines Product Owners? Wie kann Product Ownern eine gute Zusammenarbeit mit dem Vorstand gelingen? Diese und weitere Fragen diskutieren Silke Kanes, Vorständin Produkte bei der Scopevisio AG , und Tim in dieser Podcastfolge. Die Ansichten von Silke bringen eine weitere, äusserst bereichernde Perspektive auf die Aufgaben der Product Owner Rolle und agiler Produktmanager. Zunächst mal geht es um die Erwartungen des Vorstands an die Rolle von Produktverantwortlichen. Dabei gibt es durchaus auch die Aufgabe, dem Vorstand die PO-Rolle zu erklären bzw. ein Verständnis für sie zu entwickeln. Silke Kanes hat selber durch ihre lange Karriere in Produktpositionen (aber auch in einigen anderen Bereichen) viel in der Zusammenarbeit mit Vorständen gelernt und zugleich auch Product Owner in ihrem Umfeld entwickelt. Daher hat sie auch interessante Tipps, auf welche Art ein Product Owner mit den fraglichen Themen bis zum Vorstand durchdringen kann. Tim und Silke besprechen weiterhin das Thema, wie man am klug mit dem Vorstand kommuniziert? Letztlich fällt die Herausforderung zur Zusammenarbeit mit dem Vorstand in den Bereich des Stakeholder Managements. Hier müssen Product Owner und Produktmanager einfach fit sein und viele Erfahrungen sammeln, um mit ihren Anliegen durchzudringen. Weitere Podcastfolgen, auf die Silke und Tim im Laufe des Gesprächs zu sprechen kommen: Stakeholder Community Mit Storytelling andere von deinen Produktideen überzeugen Data-Fluent Product Manager Silke Kanes freut sich über den Kontakt zu euch. Für weitere Fragen oder Anliegen erreicht ihr sie am besten auf LinkedIn . Folgt ihr dort auch gerne. Ansonsten bietet ihre persönliche Homepage (silkekanes.com) mit ihrem Blog auch einen schönen Blick "hinter die Kulissen" ihres spannenden Werdegangs. Welche Erfahrungen hast du in der Zusammenarbeit zwischen Vorstand und Product Owner gemacht? Uns interessiert hier sowohl die Sichtweise der POs als auch von Führungskräften. Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [ https://bit.ly/3Why63K ]…
D
Die Produktwerker
Oliver & Dominique im Gespräch In dieser Folge wurde auf folgende Quellen verwiesen: Das Product Ownership Evolution Modell ( https://productownership.de/poem/ ) Delegation Poker ( https://management30.com/practice/delegation-poker/ )
Büşra Coşkuner im Gespräch mit Oliver Als Produktmanagerin und Product Ownerin sollte ich die relevanten Daten zu meinem Produkt kennen. Und diese Daten dann für die Entscheidungsfindung heranziehen. Oliver hat sich in dieser Podcast-Folge die Product Management Coach und Trainerin Büşra Coşkuner eingeladen, um in das Thema Data-Fluent Product Manager, gute Metriken und hilfreiche Frameworks einzutauchen. Zu Beginn des Gesprächs reflektieren die beiden, dass Entscheidungen nach ihren Erfahrungen in der Produktentwicklung in der Regel noch zu sehr aus dem Bauch heraus getroffen werden. Daten können dabei helfen, die Qualität von Entscheidungen zu verbessern. Allerdings sollte ich als PO nicht in die Falle laufen, zu viele Daten zu sammeln, sondern mich auf die wirklich relevanten Daten zu konzentrieren. Die Beschäftigung mit Frameworks kann ein Startpunkt sein, die Sprache der Daten zu erlernen - spricht ein Data-Fluent Product Manager zu werden. So kann ich Kommunikation verändern und bei meinen Stakeholdern Vertrauen schaffen. Denn Wissen führt ihrer Meinung nach zu Vertrauen. Wie immer schließt die Folge mit ganz praktischen Tipps und Tricks von unserer Gesprächspartnerin. Falls Du mit Büşra Kontakt aufnehmen oder ihr folgen möchtest, kannst Du Dich über ihr LinkedIn Profil mit ihr verbinden. Sie schreibt regelmäßig auf LinkedIn und hat auch einen sehr guten Blog zu diversen Themen für Product Manager.…
Tim und Dominique im Gespräch Der Produktschnitt im Kontext der agilen Organisationsentwicklung bezieht sich auf die Aufteilung der Teams rund um die Entwicklung eines Produkts oder einer Produktlinie. Es geht darum, die Teams so zu strukturieren, dass sie effektiv und effizient zusammenarbeiten können, um die Produktentwicklung voranzutreiben. Durch eine kluge Aufteilung der Verantwortlichkeiten wird sichergestellt, dass jedes Team über eine klare Aufgabe verfügt und seine Expertise in diesem Bereich entwickeln kann. Der Produktschnitt spielt eine entscheidende Rolle bei der Förderung agiler Prinzipien und der Maximierung des Produkterfolgs. Durch die Aufteilung der Teams nach Produkten, Produktkomponenten oder Kundensegmenten wird eine hohe Spezialisierung ermöglicht. Jedes Team kann sich auf seinen zugewiesenen Bereich konzentrieren und ein tiefes Verständnis entwickeln, was zu schnelleren und effizienteren Ergebnissen führt. Gleichzeitig fördert der Produktschnitt die Zusammenarbeit zwischen den Teams, um sicherzustellen, dass die verschiedenen Teile des Produkts gut aufeinander abgestimmt sind. Genauso kann sich dies aber auch gegenteilig auswirken, wenn zu große Abhängigkeiten zwischen den Teams entstehen. Ansätze für den Produktschnitt Es gibt verschiedene Ansätze zur Aufteilung der Teams im Produktschnitt, die je nach den Anforderungen und Gegebenheiten der Organisation gewählt werden können. Eine Möglichkeit besteht darin, die Teams nach Produktkomponenten oder den Schritten eines Transaktionsprozesses zu strukturieren. Jedes Team ist dann für einen bestimmten Teil des Produkts verantwortlich und trägt die Verantwortung für dessen Entwicklung und Verbesserung. Eine andere Option besteht darin, die Teams nach Kunden- oder Marktsegmenten oder Regionen zu gliedern, sodass jedes Team auf die Bedürfnisse und Anforderungen einer bestimmten Zielgruppe spezialisiert ist. Eine dritte Möglichkeit ist die Aufteilung nach spezifischen Funktionen, bei der jedes Team bestimmte Aufgaben oder Funktionen übernimmt, unabhängig vom Produkt oder Kundensegment. Die Teamstruktur im Rahmen des Produktschnitts hat viele Vorteile. Einer der wichtigsten Vorteile ist, dass die Teams sich auf spezifische Bereiche fokussieren und ein tiefes Verständnis für diese entwickeln können. Dadurch können sie effektiver arbeiten und spezifischer einen ganz bestimmten Teil des Produkts verbessern, da sie sich auf ihre spezielle Expertise und ein tiefes Nutzerverständnis konzentrieren können. Gleichzeitig erfordert der Produktschnitt die Zusammenarbeit und den Wissensaustausch zwischen den Teams, um sicherzustellen, dass die verschiedenen Teile des Produkts gut aufeinander abgestimmt sind. Die Wahl der geeigneten Teamstruktur hängt von verschiedenen Faktoren ab, wie zum Beispiel der Komplexität des Produkts, den Anforderungen der Kunden und den vorhandenen Ressourcen. Es ist wichtig, die Teamstruktur kontinuierlich zu evaluieren und anzupassen, um sicherzustellen, dass die Teams effektiv arbeiten und dass das Produkt schnell und effizient entwickelt wird. Ein Produktschnitt kann bei der agilen Produktentwicklung viele Vorteile bringen, aber es gibt auch einige mögliche Probleme, die bei der Implementierung auftreten können. Eine große Herausforderung besteht darin, die Abhängigkeiten zwischen den verschiedenen Teams zu managen. Wenn die Teams unabhängig voneinander arbeiten, kann es zu Verzögerungen kommen, wenn eines der Teams nicht rechtzeitig fertig wird oder auf die Arbeit eines anderen Teams angewiesen ist. Ein weiteres Problem ist die Komplexität der Koordination, insbesondere bei größeren Produkten oder Organisationen. Es ist wichtig, effektive Kommunikations- und Koordinationsmechanismen zu etablieren, um sicherzustellen, dass alle Teams auf dem gleichen Stand sind und effektiv zusammenarbeiten können. Ein weiteres mögliches Problem ist die Gefahr der Silo-Bildung. Wenn die Teams zu stark in ihre spezifischen Bereiche eingebunden sind, kann dies dazu führen, dass sie isoliert voneinander arbeiten und wenig Einblick in die Arbeit der anderen Teams haben. Dies kann die Zusammenarbeit und den Informationsaustausch beeinträchtigen und zu ineffizienten Prozessen führen. Um dem entgegenzuwirken, ist es wichtig, den Fokus auf die Gesamtvision des Produkts zu halten und Mechanismen zu schaffen, die eine enge Zusammenarbeit und den Austausch von Informationen zwischen den Teams fördern. Zum Thema dieser Episode passt auch diese Folge sehr gut: Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner Kurz nach unserer Veröffentlichung ist gerade ein anderer deutschsprachiger Podcast, der SoftwareArchitekTOUR-Podcast, über fachliches Schneiden mittels Domain Driven Design (DDD) erschienen. Hier erfolgt die Betrachtung aus eher aus technischer Sicht von erfahrenen Software-Architekten: Episode 93: Domain-driven Transformation – Mit DDD Legacy-Systeme transformieren Welche Erfahrung habt ihr schon mit den verschiedenen Teamstrukturen in der Produktentwicklung gemacht? Waren sie positiv oder gab es Probleme? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K…
Nader Fadl im Gespräch mit Tim Fake Door Tests werden genutzt, um das Interesse und die potenzielle Nachfrage für ein Produkt zu testen, bevor es tatsächlich entwickelt oder eingeführt werden. Letztlich kann dies ein entscheidender Schritt zum Problem-Solution-Fit sein. Tim hat mit Nader Fadl einen Experten zu Gast, der in dem Themenfeld promoviert sowie als Dozent für Markenkommunikation und Marketing Analytics aktiv ist. Nader geht somit von der wissenschaftlichen Seite an Methoden des User Testing heran, zugleich aber auch als Praktiker. So hat er mit seinem StartUp experial durch den Einsatz von No-Code und KI eine stark vereinfachte und schnelle Möglichkeit zur Umsetzung von Fake Door Tests geschaffen. Falls ihr diese Testing-Methode noch nicht kennt: Bei Fake Door Tests wird quasi eine "falsche Tür" erstellt, wie zum Beispiel eine eigene Landing Page oder ein Menüpunkt, Teaser o.ä. in bestehenden Apps oder Webseiten, die jeweils das Produkt oder die Dienstleistung bewerben. Potenzielle Kunden können auf diese "Tür" klicken oder reagieren, und basierend auf ihrem Verhalten und Feedback wird entschieden, ob es sich lohnt, das Produkt oder die Dienstleistung tatsächlich zu entwickeln. Es ist also Teil der Product Discovery, um dem Value Risk zu begegnen (hierzu haben sind in diesem Podcast bereits verschiedene Episoden erschienen). Es ermöglicht Unternehmen somit, wertvolle Informationen zu sammeln, um fundierte Entscheidungen zu treffen und Ressourcen effizient einzusetzen. Folgende Podcast-Episoden passen zu diesem Thema: Kontinuierliche Product Discovery in Teams etablieren Welche Rolle Product Discovery in der Arbeit von Product Ownern spielen sollte Wer weitere Fragen an Nader Fadl hat oder von ihm bei der Durchführung schneller Experimente unterstützt werden möchte, kann mit ihm am Besten via LinkedIn , per Mail (nader@experial.ai) oder über die Webseite experial.ai in Kontakt treten. Oder ihr folgt seinem StartUp experial auf LinkedIn . Welche Erfahrung habt ihr schon mit Fake Door Tests gemacht? Scheiten sie bei euch auch meist an der Umsetzungsdauer? Man redet vielleicht drüber, setzt sich aber am Ende dann doch nicht ein und vertraut auf sein Bauchgefühl? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K…
Martin Beschnitt im Gespräch mit Dominique Product Owner haben oft das Ziel, ihre Produkte so benutzerfreundlich wie möglich zu gestalten. Um dieses Ziel zu erreichen, brauchen sie oft Unterstützung im Bereich User Experience. Wenn es aus unterschiedlichen Gründen keine interne Hilfe gibt, wird gerne auf einen UX-Dienstleister zurückgegriffen. Dieser kann das Produktteam bei der Erstellung von Benutzerforschungen, der Gestaltung von Interaktions- und Visualisierungskonzepten und der Validierung von Designideen unterstützen. Da es aber auch in der Zusammenarbeit ein paar Herausforderungen gibt, unterhält sich Dominique in dieser Folge mit Martin Beschnitt ( https://www.linkedin.com/in/martin-beschnitt/) , geschäftsführender Gesellschafter der eresult GmbH ( https://www.eresult.de/) . Im Gespräch besprechen die beiden beispielsweise darüber, ob UX oft missverstanden wird und welche Probleme bei der Umsetzung von UX in agilen Umfeldern auftreten können. Viele Menschen denken, dass UX nur die Gestaltung von Benutzeroberflächen umfasst, während es in Wirklichkeit um die Erfahrung des Benutzers im gesamten Produktzyklus geht. Diese Herausforderungen treten eben verstärkt auf, wenn ein UX-Dienstleister ins Boot gehlt wird. Es wird auch besprochen, wie ein Dienstleister am besten in das Produktteam integriert werden kann und welche Voraussetzungen für eine ideale Zusammenarbeit mit einem PO und einem UX-Dienstleister erfüllt sein sollten. Abschließend werden Tipps gegeben, wie POs besser mit UX-Dienstleistern zusammenarbeiten können. Natürlich sind UX-Dienstleister nur eine Art externer Unterstützung, aber mit dieser Folge soll eine Hilfestellung gerade im Bereich Discovery gegeben werden. Falls ihr mehr zur Zusammenarbeit mit Dienstleistern hören wollt, empfehlen wir euch diese Folgen: Dienstleister-Steuerung durch eine Retained-Organisation ( https://produktwerker.de/retained-organisation-dienstleister-steuerung/ ) Zusammenarbeit mit einem externen Team vom Dienstleister ( https://produktwerker.de/externes-team-eines-dienstleisters/ ) Welche Erfahrungen hast du mit UX-Dienstleistern gesammelt und was kannst du als Tipps anderen Product Ownern mitgeben? Und wir freuen uns, wenn du deine Learnings mit uns in einem Kommentar auf der Seite zur Folge ( https://produktwerker.de/ux-dienstleister/ ) oder auf unserer Produktwerker LinkedIn-Seite ( https://www.linkedin.com/company/produktwerker ) teilt.…
Tim und Dominique im Gespräch Wie kann man durchsetzungsstark als Product Owner sein und wirken, obwohl man in der Regel keine formale Macht hat? Was tun, wenn höhergestellte Menschen in der Organisation auf ihren Rang verweisen oder manchmal auch einfach nur ganz subtil ihre formale Macht ausüben? Dominique und Tim betrachten in dieser Folge also vor allem Herausforderungen im Umgang mit höhergestellten Stakeholdern. Oder anderes: von Hierarchie und Macht zu mehr Augenhöhe. Dominique und Tim nähern sich dem Thema über die Frage, was es denn für mögliche Konsequenzen und Auswirkungen hat, wenn ein solches Verhalten vorliegt, Druck ausgeübt wird oder ähnliches. Wie können wir in solch einem Umfeld unserer Hauptaufgabe als Product Owner nachkommen, erfolgreiche Produkte zu entwickeln und sogar den Wert des Produktes zu maximieren? Der Scrum Guide ist da ja sehr klar und sagt, dass Product Owner nur erfolgreich können, wenn die gesamte Organisation seine oder ihre Entscheidungen respektiert. Aber wo gibt es diesen Zustand denn wirklich in real existierenden Organisationen? Also eine Entscheidungsstärke, obwohl wir in der Regel nicht mit formaler Macht ausgestattet sind. Wie können wir in solch einem Kontext auf Augenhöhe kommen? Die beiden diskutieren Lösungsansätze und erklären ein mögliches Vorgehen. Dabei es vor allem um effektive Kommunikation, d.h. mit hoher Transparenz und sehr viel Klarheit zu kommunizieren. Zugleich muss man aber auch eine verständnisvolle Haltung für andere Ebenen in der Organisation einnehmen. Der zeitliche Horizont von Diskussionen, die auf den unterschiedlichen Ebenen geführt werden, ist in der Regel ein ganz anderer. Darauf muss ich mich als Product Owner auch einlassen. Eine gute Darstellung hierzu gibt es mit dem Pace Layering Modell von Stewart Brand . Auch das "Nein"-Sagen will als Product Owner gelernt sein. Dabei geht es natürlich nicht, um ein stures "Nein", sondern um ein gut informiertes und begründetes "Nein", was in der Regel zu sehr guten Diskussionen und einem verbesserten gegenseitigen Verständnis führt. Wie üblich gibt es gegen Ende der Folge noch besondere Tipps, wie man durchsetzungsstark als Product Owner trotz Hierarchie werden kann. Die folgenden anderen Episoden unseres Podcasts passen zu diesem Thema: Episode 26: Seine Stakeholder kennen und richtig analysieren Episode 50: Starke Produktmanager entwickeln Episode 116: Der CEO-Test - keine falschen Kompromisse Episode 108: Nein sagen als Product Owner Weitere erwähnte Quelle: Roman Pichler: Be a balanced product leader, not a feature broker or product dictator Hast du machmal auch Schwierigkeiten gegen höher gestellte Kolleg:innen oder Stakeholder durchsetzungsstark als Product Owner zu agieren? Oder gelingt es dir schon ganz gut? Welche Strategien hast du dabei entwickelt? Wenn du Tipps und Empfehlungen für uns und andere Product Owner hast, würden wir uns über deinen Input freuen? Wir sind wirklich sehr neugierig zu erfahren, welches Vorgehen in deinem Kontext erfolgreich ist. Und wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K…
Frederik Obermaier im Gespräch mit Dominique Immer mehr Unternehmen setzen zurecht auf Nachhaltigkeit und auch in der technischen Entwicklung wird der Fokus zunehmend auf umweltfreundliche Lösungen gelegt. Daher spricht Dominique mit Frederik Obermaier ( https://www.linkedin.com/in/frederik-obermaier-563850158/) , über die Herausforderungen und Möglichkeiten, die sich für Nachhaltigkeit in der digitalen Produktentwicklung existieren. Frederik ist Digital Product Manager bei Epal und hat sich auch im Rahmen seiner Masterthesis mit dem Thema befasst. In der Podcastfolge wurde zunächst erklärt, was unter Nachhaltigkeit in der digitalen Produktentwicklung verstanden wird. Immerhin kann Nachhaltigkeit sich auf das Ergebnis und auch den Prozess der Produktentwicklung beziehen. Am Ende geht es vor allem um den schonenden Umgang mit Ressourcen (wozu auch die Lebenszeit von Menschen gehört) und die Vermeidung von Umweltbelastungen während der Entwicklung, dem Betrieb und der Nutzung von digitalen Produkten. Aber auch schon in der Konzeption kann Nachhaltigkeit berücksichtigt werden. Dabei sind Transparenz und Kommunikation innerhalb der Unternehmen wichtig, damit alle Beteiligten über die Auswirkungen ihrer Entscheidungen auf Nachhaltigkeit informiert sind und auch die Möglichkeit haben, ihre Ideen und Vorschläge einzubringen. Auch die Einbeziehung von externen Experten und Stakeholdern kann dazu beitragen, dass alle Perspektiven berücksichtigt werden und nachhaltige Lösungen entwickelt werden. Um die Nachhaltigkeit von digitalen Produkten zu verbessern, ist es darüber hinaus wichtig, dass Menschen, die das Produkt nutzen, über die Auswirkungen ihrer Handlungen informiert werden. Dazu können beispielsweise Aufklärungskampagnen beitragen. Auch die Einbeziehung von Nachhaltigkeitsaspekten in die Nutzerbedienung kann dazu beitragen, dass Menschen bewusster mit den digitalen Produkten umgehen. Ein schönes Beispiel hierfür ist AirBnB und seine Auswirklungen auf das nachbarschaftliche Umfeld einer Wohnung. Dieser Effekt wird nämlich oft vergessen. Insgesamt gibt es also viele Möglichkeiten, Nachhaltigkeit in der digitalen Produktentwicklung zu fördern. Dabei ist es wichtig, dass das Thema in allen Phasen der Produktentwicklung berücksichtigt wird. Nur so können wir gemeinsam eine nachhaltigere digitale Zukunft gestalten.…
Tim und Dominique im Gespräch Die UX-Vision ist ein wertvolles Instrument, wenn es darum geht die Kräfte eines Teams auf das gleiche Ziel zu fokussieren. Im Gegensatz zur Produktvision beschreibt die UX-Vision aber in erster Linie, wie ein Mensch die Interaktion mitd em Produkt erleben und anschließend auch beschreiben soll. Nicht jedes Produkt erzeugt das gleiche Nutzungserlebnis bzw. sind je nach Produkttyp andere Faktoren wichtig. Eine Waschmaschine wird andere relevante Faktoren haben als eine Banking-App. Doch bevor jeder im Team eine eigene Vorstellung entwickelt, wird eine gemeinsame UX-Vision entwickelt und alle Teammitglieder können sich dadurch ein geteiltes, mentales Modell erzeugen. Bei jeder noch so kleinen Entscheidung können sie dann immer fragen, wie ihre Entscheidung auf die für ihr Produkt wichtigen Aspekte der User Experience einzahlen würde. Wenn die wichtigen UX-Faktoren für das eigene Produkt bekannt sind, können diese auch genutzt werden, um bei der Priorisierung der Product Backlog Items eine informierte Entscheidung zu treffen. Wie groß ist der Einfluss eines PBI auf einen Faktor der User Experience? Dies zu ermittelt ist manchmal gar nicht so leicht. Darum hat Dominique mit Andreas Hinderks ( https://www.linkedin.com/in/andreashinderks ) das UX Poker entwickelt, bei dem ein Team den EInfluss eines PBI auf einen Faktor bewerten kann und dabei auch bewährte Techniken aus dem Planning Poker zurückgreifen kann. Einen aktuellen Forschungsartikel findet ihr dazu hier. Nachdem nun im Product Backlog jedes Item nach seinem Einfluss auf die UX bewertet werden kann, braucht es auch eine Möglichkeit des Messens. Dazu empfiehlt Dominique in dieser Folge den UEQ+. Mehr zu diesem Fragebogen findet ihr unter https://ueqplus.ueq-research.org/ . Der UEQ+ ist eine modulare Erweiterung des User Experience Questionnaire (UEQ) und enthält eine größere Liste von möglichen UX-Faktoren. Oft sind da schon die wichtigsten Faktoren für das eigene Produkt dabei. In der Folge wurde auf diese früheren Beiträge von uns verwiesen: Agiles Schätzen: Planning Poker ( https://produktwerker.de/agiles-schaetzen-planning-poker/ ) Wie die Produktvision hilft, Product Ownern eine Richtung zu geben ( https://produktwerker.de/wie-die-produktvision-hilft-product-ownern-eine-richtung-zu-geben/ ) Video vom Live-Event zur Entwicklung von UX-Visionen ( https://youtu.be/B1lAA4iWkH4 ) Wenn du Tipps, Tricks und Erfahrungen für uns alle hast, freuen wir uns über dein Feedback. Lass einfach einen Kommentar unter https://produktwerker.de/ux-vision/ da oder kommentiere auf unserer Produktwerker LinkedIn-Seite ( https://www.linkedin.com/company/produktwerker) .…
Jennifer Rolle im Gespräch mit Tim Der individuelle organisatorische Kontext, in dem wir als Product Owner agieren können, ist mit entscheidend für unsere eigene Wirksamkeit. Grund genug einmal explizit auf die Rolle von HR in agilen Transformationen zu schauen. Dafür ist Jennifer Rolle von den hr pioneers bei Tim zu Gast in unserem Podcast. Jennifer begleitet Unternehmen bei ihren agilen Transformationsprozessen. Zu Beginn ihres Gesprächs berichtet Jennifer, wann und warum HR in der Regel in den Veränderungsprozess mit involviert wird. Ausgehend von dem Wissenstand über neu entstehende Rollen und Verantwortlichkeiten reflektieren die beiden, welche Probleme es beispielsweise bei der Ausgestaltung dieser neuen Rollen und der Etablierung in Fachbereichen gibt - vor allem bei einem nicht klar kommunizierten Verständnis der Unterschiede zwischen Job & Rolle oder Product Owner & Product Manager. In der spannenden Diskussion kommen Tim und Jennifer auch an den Themen Führungsrolle als Product Owner, Gehaltsdiskussion und interne Bewerbungsprozesse auf eine PO Rolle vorbei. Spannend sind die Einblicke, wie der HR Bereich unterstützen kann, in die neue Verantwortlichkeit hineinzuwachsen. Die Episode schließt wie üblich mit ganz praktischen Tipps für Dich als Product Owner ab. Referenzen aus dieser Folge: Agile HR Manager Training (Certified) -> https://hr-pioneers.com/leistungen/trainings/certified-agile-hr-manager/ Interessante, zum Thema passende Folgen: Welche Aufgaben gehören zur Product Owner Rolle? Ownership verpflichtet Product Owner als Agile Leader Kontakt zu Jennifer Jennifer freut sich, wenn Du bei Fragen mit ihr Kontakt aufnimmst. Am einfachsten schreibst Du sie über ihr LinkedIn-Profil an. Sie freut sich auch über ein Email, alle Kontaktdaten findest Du auf ihrer Profilseite bei den hr pioneers . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (mit Terminen für unsere kostenfreien Events) -> https://bit.ly/3Why63K…
Dominique & Oliver im Gespräch Für Organisationen entsteht durch die agile Produktentwicklung eine besondere Herausforderung. Wissen muss innerhalb eines Teams aber auch darüber hinaus ausgetauscht und weitergegeben werden. Eine mittlerweile bewährte Möglichkeit des teamübergreifenden Austauschs bieten beispielsweise Communities of Practice. In diesen tauschen sich Menschen zu einem bestimmten Themengebiet aus und lernen voneinander. Dominique und Oliver sprechen daher in dieser Folge über Product Owner Communities, den Communities of Practice für Product Owner. In der Praxis begegnen uns Product Owner Communities in ganz unterschiedlicher Form. Von Buchclubs hin zu Lerngruppen und Orten für kollegiale Fallberatung besprechen die beiden verschiedene Erscheinungsformen der PO Communities, klären aber auch, wie man als EInzelkämper oder Einzelkämpferin von einer externen Community profitieren kann. Folgende Referenzen haben Oliver und Dominique in dieser Folge erwähnt: Cultivating Communities of Practice von Wenger, McDermott und Snyder ( https://www.amazon.de/Cultivating-Communities-Practice-Managing-Knowledge/dp/1578513308 ) Der interne UX-Stammtisch - Entwicklung einer Community of Practice für UX-Professionals im Unternehmen ( https://dl.gi.de/handle/20.500.12116/5472 ) Agiles Produktmanagement mit Scrum - Roman Pichler ( https://www.romanpichler.com/romans-books/agile-product-management-with-scrum/ ) Rund um die Vernetzung und die Weiterentwicklung von Product Ownern empfehlen wir euch noch folgende Folgen: Als Product Owner erfolgreich zusammenarbeiten ( https://produktwerker.de/als-product-owner-erfolgreich-zusammenarbeiten/ ) Das Product Owner Team (/ https://produktwerker.de/product-owner-team/ ) Sei dein eigenes Produkt! – als PO seine Weiterentwicklung steuern ( https://produktwerker.de/sei-dein-eigenes-produkt/ ) Welche Erfahrungen hast du beim Aufbau von Product Owner Communities gemacht? Was hat gut und was vielleicht auch gar nicht funktioniert? Wenn du Tipps, Tricks und Erfahrungen für uns alle hast, freuen wir uns über dein Feedback. Auch der Austausch hier ist eine Art der Community und des gemeinsamen Lernens. Daher freuen wir uns besodners über einen Kommentar hier oder auf unserer Produktwerker LinkedIn-Seite ( https://www.linkedin.com/company/produktwerker) . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (mit Terminen für unsere kostenfreien Events) -> https://bit.ly/3Why63K…
Tim Herbig im Gespräch mit Oliver Wir haben in diesem Podcast schon öfter über die Bedeutung der Produktstrategie für Product Owner und agile Produktmanager gesprochen. Will ich eine Produktstrategie entwickeln, dann greifen viele Product Owner auf die bekannten Templates und Cavases zurück. Tim Herbig, Product Coach und Author aus Erfurt, teilt im Gespräch mit Oliver seine Gedanken, wie das Erarbeiten der Produktstrategie auch ohne diese Tools gelingen kann. Die beiden starten die Diskussion mit einer Definition von Produktstrategie. Hier referenziert Tim auf das Buch von Roger Martin. Spannend ist die kritische Haltung von Tim, dass die komplette Strategie meist nicht in Workshops durch das Ausfüllen eines der gängigen Canvases entsteht. Für Bestandteile der Strategie, wie beispielsweise die Produktvision oder eine Wettbewerbsanalyse macht ein Workshopformat hingegen wieder viel Sinn. Tim erläutert darüber hinaus, wie ich OKRs und Produktstrategie sinnvoll miteinander verbinden kann. Seine These: Ohne eine nützliche Produktstrategie kann ich keine sinnvolle OKRs definieren. Abschließend reflektieren die beiden, wen ich an dem Strategie-Erstellungsprozess beteiligen und welche Bestandteile erarbeitet werde sollten, damit die Produktstrategie mich auch in meiner Arbeit unterstützt. Wie immer schließt die Folge mit konkreten Tipps und Tricks ab. Folgende Bücher und Blogbeiträge haben Tim und Oliver in dieser Folge erwähnt: Newsletter von Tim -> https://herbig.co/newsletter/ Roger Martin - Playing to Win -> https://www.amazon.de/Playing-Win-Strategy-Really-Works/dp/142218739X/ Ravi Metha - Product Strategy Stack -> https://www.reforge.com/blog/the-product-strategy-stack Tim Herbig - Product Strategy Ressources Hub https://herbig.co/product-strategy-hub/ Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (mit Terminen für unsere kostenfreien Events) -> https://bit.ly/3Why63K…
Dominique und Tim im Gespräch In Trainings, Workshops und Coachings bekommen wir immer wieder Fragen zur Abnahme von User Stories gestellt. Grund genug, zu diesem Thema mal eine Episode aufzunehmen. Dominique und Tim nähern sich dem Thema über die Frage, was denn überhaupt eine Abnahme ist und wo sie sonst stattfindet. Schnell wird klar, dass es sich dabei um Vertragssituationen handelt. Hierbei nimmt der Auftraggeber die Leistung des Auftragnehmer ab. Das Allein zeigt schon, dass die Frage im agilen Kontext eines Scrum Teams vielleicht falsch gestellt ist. Es besteht kein Vertragsverhältnis zwischen Product Owner und Developern, daher ist im engeren Sinne auch nichts abzunehmen. User Stories und andere Product Backlog Elemente enthalten dagegen sogenannte Akzeptanzkriterien, die wir auch in einer anderen Folge schon mal ausführlich betrachtet haben. Es geht also eher um die Frage, wann eine erstellte Lösung im Hinblick auf das zu lösende Problem als akzeptabel gelten kann. Die beiden diskutieren also, wie man die Akzeptanz einer User Story organisieren kann und welche Rolle dabei die Definition of Done spielt. Dabei geht es natürlich auch um die Frage, wann hierfür der beste Zeitpunkt innerhalb des Sprints ist. Und was passiert, wenn eine User Story nicht "abnahmefähig" ist? Wie üblich gibt es gegen Ende der Folge noch besondere Tipps, wie man mit der Frage zur Abnahme von User Stories umgehen kann. Die folgenden anderen Episoden unseres Podcasts passen zu diesem Thema: Akzeptanzkriterien richtig einsetzen Arten von Product-Backlog-Einträgen: Was gibt's neben User Stories noch? Die Definition of Done aus Sicht von Product Ownern Habt ihr die Diskussionen auch, von wem und wann die User Stories abgenommen werden sollen? Wie regelt ihr das? Wenn du Tipps für uns alle hast, würden wir uns über deinen Input freuen? Wir sind wirklich sehr neugierig zu erfahren, welches Vorgehen in deinem Kontext erfolgreich ist. Und wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite . Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (mit Terminen für unsere kostenfreien Events) -> https://bit.ly/3Why63K…
Roman Pichler im Gespräch mit Dominique In dieser Folge unterhält sich Dominique mit Roman Pichler über das Thema Produktstrategie. Roman hat gerade erst eine neue Auflage seines Buchs Strategize veröffentlicht und die beiden nehmen dies zum Anlass, um über dieses wichtige Thema zu sprechen. Roman sieht dabei die Produktstrategie als einen Plan bzw. den Weg wie man eine Produktvision erreichen möchte. Die beiden sprechen auch über die Probleme beim Entwickeln von Strategien. Oft beobachtet Roman beispielsweise, dass in einer Organisation gar nicht richtig klar ist, was das Produkt ist. Daneben sieht er auch eine fehlende Bevollmächtigung der Produktmanager bzw. Scrum Product Ownern. Aus der Produktstrategie werden dann Teilziele abgeleitet und eine zielorientierte Roadmap entwickelt. Mit Hilfe der zielorientierten Roadmap können Entwicklungsteams angeleitet und Stakeholder miteinander abgestimmt werden. Von Feature Roadmaps rät Roman dabei aber explizit ab, da es ihm weniger um die Auslieferung von Features geht, sondern mehr um das Erreichen von Zielen. Ein besondere Idee hat Roman noch für die Überführung der Strategie ins Product Backlog. Das aktuelle Product Goal wird als alleiniges Kriterium für die Elemente im Product Backlog genommen und nur Elemente, die auf dieses Ziel einzahlen sollten im Backlog aufgenommen werden. Damit wird das Product Backlog recht schlank aber sehr auf das Produktziel fokussiert. Roman war bereits einmal bei uns zu Gast und hat darüber gesprochen, welche Herausforderungen und Praktiken bestehen, um als Product Owner zu führen ( https://produktwerker.de/how-to-lead-in-product-management/) . Wenn euch das Thema Produktstrategie interessiert, empfehlen wir euch noch folgende Folgen: The Product Field ( https://produktwerker.de/product-field/ ) Eine Produktstrategie entwickeln ( https://produktwerker.de/produktstrategie-entwickeln/ ) Wardley Mapping - Produktstrategie ist wie Schach ( https://produktwerker.de/wardley-mapping/ )…
Oliver und Tim im Gespräch Als PO verantworten wir in der Regel nicht ein einziges Produkt während unseres langjährigen Product Owner Lebens. Produkte kommen und gehen, wir entwickeln neue Ideen oder begleiten ehemalige Cash-Cows bis ans Ende ihres Produktlebenszykluses. Und es kann vorkommen, dass wir das „Problem Produkt“ erben, an dem niemand in unserer Organisation gerne arbeiten möchte. In dieser Folge sprechen Oliver und Tim über genau diese Situation. Wir können dann als Product Owner nicht auf der grünen Wiese agieren, sondern spielen nun eher im "Brown Field". Häufig bringt die Übernahme solch eines Produktes eine Reihe von Problemen mit sich: Es ist nur noch schwer erweiterbar oder wartbar, es existieren sehr viele Abhängigkeiten zu anderen Produkten oder Mitarbeitenden. Darüber hinaus lässt auch die Verfügbarkeit/Stabilität zu wünschen übrig. Oliver und Tim reflektieren in dieser Folge, an welchen Symptomen wir erkennen können, dass wir an solch einem Problem Produkt arbeiten. Und sie gehen in ihrer Diskussion einen Schritt weiter, indem sie möglichen Ursachen auf den Grund gehen. Die Folge schließt mit unterschiedlichen Lösungsansätzen ab. Was kann ich al sProduct Owner ganz konkret tun, wenn ich mich in der oben beschriebenen Situation befinde? Hierzu geben Oliver und Tim wie gewohnt eine Reihe von praktischen Tipps und Beispiele aus der eigenen Product Owner Praxis.…
Michael Mahlberg im Gespräch mit Tim Wir sprechen in unserem Podcast über Product Owner und meinen damit implizit Scrum Product Owner. Doch was ist eigentlich mit Kanban und Product Ownern? Kennt Kanban POs? Über diese und viele weitere Fragen spricht Tim in dieser Folge mit Michael Mahlberg, Geschäftsführer von The Consulting Guild GmbH . Als Berater und Begleiter in großen Veränderungsvorhaben und ausgewiesener Kanban-Experte teilt Michael zu Beginn dieser Episode seine Sicht auf die Unterschiede zwischen Scrum und Kanban. Kanban ist Change und startet bei dem, was schon da ist. Die beiden stellen fest, dass die Definition von Product Owner sehr schwammig ist. Diese Unschärfe bezieht sich nicht nur auf die dreiviertel Seite an Beschreibung im Scrum Guide sondern auch in der Interpretation vieler Organisationen. Es gilt, die Frage zu beantworten: Welche Art von Product Owner wollen wir in dem jeweiligen Kontext einsetzen. Michael führt anschließend aus, was Kanban generell zu Rollen sagt. Und ergänzt seine persönlichen Beobachtungen aus der eigenen Beraterpraxis. Wie immer schließen wir mit Tipps und Tricks für dich als PO ab. Weitere Quellen Aufzählungs-Text- Michael Mahlberg: Why are there no Product Owners in Kanban Kanban University: The Official Guide to the Kanban Method Buchempfehlung: Essential Kanban Condensed David Anderson: Kanban - Successful evolutionary change for your technology business Falls du Kontakt mit Michael aufnehmen möchtest, kannst du ihn gerne über Webseite seiner Firma ( http://consulting-guild.de/ ) oder gerne auch direkt via Mail unter mm@consulting-guild.de kontaktieren. Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (mit Terminen für unsere kostenfreien Events) -> https://bit.ly/3Why63K…
Oliver und Tim im Gespräch Manchmal erfordert das Umfeld einer Produktentwicklung mit einem externen Entwicklungspartner eine Umsetzung als "Agiler Festpreis", also einer bestimmten Vertragsform. Was das heißt, wie man es erfolgreich angehen kann und welche Erfahrungen wir damit schon gemacht haben, besprechen Oliver und Tim in dieser Folge. Kaum eine agile Produktorganisation wird sich vermutlich darum reißen, in einem Festpreis-Konstrukt ein Produkt zu entwickeln, aber die Rahmenbedingungen können wir uns in der Realität nicht immer "backen". So gibt es natürlich immer noch viele Produktvorhaben, die in Form eines Projektes gestartet werden und bei dem ein externer Dienstleister zum Einsatz kommt. Bei der Beauftragung von extern Dienstleistungsunternehmen fordern zunehmend mehr Einkaufsabteilungen großes Organisationen oder Konzerne dabei die Beauftragung als "Festpreis", d.h. nicht mehr in Form eines Dienstleistungsvertrags ("Time & Material"). Wie passt das aber zu einer agilen Vorgehensweise? Auch wenn ein agiler Festpreis nach unserer Beobachtung in letzter Zeit zwar zunehmend seltener als Vertragsform vorkommt, als noch vor einigen Jahren, ist es spannend sich dieses Konstrukt noch mal zusammen anzusehen. Vermutlich ist die Forderung nach einem agilen Festpreis auch eher einem nicht agilen Umfeld geschuldet. D.h. die Budgetierungs- und Einkaufsprozesse des Unternehmens sind noch nicht auf die Vorgehensweise einer agilen Produktentwicklung eingestellt. Somit ist ein "Agiler Festpreis" u.E. letztlich nur ein Hilfskonstrukt, um eine agile Produktentwicklung im Kontext eines nicht agilen Organisationsumfeldes starten zu können. Tim berichtet von seinen Erfahrungen eines großen agilen Festpreis-Projektes, das er in einem Konzernumfeld zusammen mit einem externen Entwicklungsdienstleister eingeführt und umgesetzt hat. Tipps was, was er heute anders machen würde und was damals geholfen hat, die Entwicklung letztlich positiv umzusetzen. Tim verweist im Gespräch rund um das Thema Team "Estimation Game" auf die Folge Agiles Schätzen: Magic Estimation . Eine weitere gute Episode unseres Podcast zu dem Themenkomplex ist sicherlich auch " Zusammenarbeit mit einem externen Team vom Dienstleister ". Aber auch andere Folgen haben sich schon mit den Dienstleister-Kontext beschäftigt. Mögliche Quellen, um tiefer in das Thema einzusteigen: Stefan Roock, Fritz-Ulli Pieper: Agile Verträge - Vertragsgestaltung bei agiler Entwicklung für Projektverantwortliche Boris Gloger, Andreas Opelt et al: Der agile Festpreis: Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge Hast du selber schon Erfahrungen mit der Vertragsform "Agiler Festpreis" gemacht? Wenn ja, welche Tipps hast du für uns alle? Wir sind wirklich sehr neugierig zu erfahren, welches Vorgehen in deinem Kontext erfolgreich ist/war. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite .…
Christian Klein im Gespräch mit Tim "Seine Inneren Antreiber zu kennen, ist der erste Schritt, um negativen Wirkungen in Stresssituationen entgegenwirken zu können." sagt unsere heutiger Gast Christian Klein, Systemischer Coach und Scrum Master sowie Geschäftsführer von paragraph eins. Tim beleuchtet mit Christian in dieser Episode das Phänomen der sogenannten "Inneren Antreiber", die sich aus dem Kontext der Transaktionsanalyse ergeben haben. "Beeil' Dich!", "Sei perfekt!", "Mach' es allen recht!", "Streng dich an!" und "Sei stark!" sind diese Inneren Antreiber laut Transaktionsanalyse. Daneben gibt es aber z.B. von Kaluza noch die beiden Beobachtungen "Sei vorsichtig!" und "Ich kann nicht!". Nach einer Erklärung der Herkunft und der Ausprägung der einzelnen Treiber - sowie einer Abgrenzung zu den sogenannten Glaubenssätzen - erläutert Christian auch anhand persönlicher Beispiele, wie diese grundsätzlich positiven Verhaltensmuster unter Stress auch umschlagen können und uns im Fortkommen behindern mögen. Um seine eigenen inneren Antreiber zu erkennen, kann der " Antreiber Test " helfen. Ihr findet ihn neben weiteren Erklärungen zu den Inneren Antreibern in einer gut strukturierten Darstellung auch der folgenden Seite von paragraph eins: hier . In der Folge nehmen Tim und Christian auch Bezug auf die folgenden älteren Episoden aus unserem Podcast: Nein sagen als Product Owner Verantwortung als Product Owner übernehmen Wenn ihr Kontakt zu Christian Klein aufnehmen möchtet und mehr mit ihm über dieses oder andere Themen sprechen möchtet, erreicht ihr ihn am Besten via E-Mail (christian.klein@paragraph1.de). Oder vernetzt euch auf LinkedIn mit ihm. Wie bewusst gehst du mit dem Thema "Innere Antreiber" oder Glaubenssätze um? Hast du dich schon mal dabei erwischt, dass sie dein Handeln in einer nicht hilfreichen Weise beeinflussen? Lass uns gerne daran teilhaben. Wir freuen uns, wenn ihr eure eigenen Erfahrungen oder Gedanken mit uns in einem Kommentar hier oder auf unserer Produktwerker LinkedIn-Seite teilt. Und falls euch der Podcast gefällt, freuen wir uns auch immer über eine Bewertung in der von euch favorisierten Podcast-App.…
Tim und Oliver im Gespräch Zu Product Roadmaps gibt es in unseren Veranstaltungen immer sehr viele Fragen der Teilnehmenden. Obwohl wir bereits vor einiger Zeit eine immer noch aktuelle und interessante Folge zu Agile Product Roadmaps veröffentlicht haben, ist es wichtig, dass sich Tim und Oliver erneut zu dem Thema unterhalten. Denn bei ihnen geistert die Idee im Kopf herum, ob Product Owner nicht mit mehreren Product Roadmaps arbeiten sollten. Wichtig für die Einordnung dieses Gedanken ist eine Abgrenzung von Project und Product Roadmaps. Daher starten die beiden auch mit einer Unterscheidung von Produkt- und Projektdenken in die Episode. Nun sind die Informationsbedürfnisse der Stakeholder und Nutzer eines Produktes sehr heterogen. Denn alle brauchen verschiedene Daten auf sich stark unterscheidenden Detailierungsgraden, um selber zielgerichtet weiterarbeiten zu können. Tim und Oliver haben sich die gängigen Typen und Templates von Product Roadmaps angesehen und kritisch in Bezug auf die vorab analysierten Informationsbedürfnisse bewertet. Dabei stellen sie den Gedanken vor, ob es hilfreich ist, alle diese Infos in eine Roadmap zu packen oder ob mit mehreren Product Roadmaps arbeiten nicht zielführender ist. Natürlich hinterfragen sie die Idee kritisch. Ist der zu zusätzliche Aufwand gerechtfertigt, führen mehrere Product Roadmaps nicht zu Verwirrung? **Quellen aus der Folge ** ProdPad: https://www.prodpad.com/resources/roadmap-course/ Roman Pichler: GO Product Roadmap John Cutler on Twitter Die Produktwerker Box: Agile Product Roadmaps - das Ende der Gant-Charts Im LinkedIn-Post rund um das Thema dieser Folge gab es eine interessante Diskussion. Dabei hat die von uns geschätzte Kollegin Büşra Coşkuner (Product Management Coach) auf ihren Artikel Agile Roadmaps in Practice verwiesen, in dem sie ihren Ansatz mehrere Roadmap Sichten zu nutzen anschaulich darstellt (inkl. Visualisierung). Insofern können wir Euch diesen Artikel auch sehr empfehlen.…
Heiko Stapf im Gespräch mit Oliver In dieser Folge ist Heiko Stapf bei uns zu Gast. Heiko ist für uns einer der Experten für agiles Produktmanagement im deutschsprachigen Raum und zeitgleich erfahrener Certified Scrum Trainer der Scrum Alliance. Aus seinen Product Owner Trainings hat er die spannendsten Fragen der Teilnehmer mitgebracht, die er gemeinsam mit Oliver diskutiert. Im ersten Teil der Episode dreht sich alles um Vorhersagbarkeit und Planung. Was sollte ich als Product Owner tun, wenn vor allem aus dem Management viel Verbindlichkeit und Commitment von mir erwartet wird? Welche Auswirkungen hat diese Erwartungshaltung auf Product Roadmaps. Eine weitere spannende Frage aus dem PO Training ist die Frage nach der Priorisierung, vor allem des Product Backlogs. Die Diskussion führt Heiko und Oliver dann zwangsläufig zur Zusammenarbeit mit Stakeholdern. Wie sollte ich priorisieren, falls meine Stakeholder konkurrierende Ziele haben? Insgesamt sehr spannende Themen mit Relevanz für jeden Produkt Owner. Und eine angeregte Diskussion zwischen den beiden, aus der du hoffentlich den einen oder anderen Impuls mitnehmen kannst. Im Gespräch verweisen die beiden auf folgende Quellen: John Cutler: Suitably Detailed Roadmap Items Martin Eriksson: The Decision StackThe Decision Stack…
Dominique und Tim im Gespräch Im Alltag müssen wir alle ständig mit anderen Menschen interagieren, sei es Small Talk, eine heiße Diskussion oder einfach nur das stille Zuhören eines Gegenübers. Dabei kommt es dauerhaft, auch wenn es nur unterbewusst ist, zum Einsatz unserer Social Skills. Als Product Owner*in ist man da nicht ausgeschlossen. Ob man mit einem Scrum Team arbeitet oder sich mit Stakeholdern austauscht, Social Skills können den Unterschied zwischen einem guten und einem schlechten PO machen. Darum unterhalten sich Tim und Dominique dieses mal über die verschiedenen Social Skills und sozialen Kompetenzen die vor allem für POs relevant sind. Dabei erkunden sie Unterschiede zwischen Hard und Soft Skills, und teilen ihre Gedanken über unterschiedliche Social Skills wie Empathie oder dem aktiven Zuhören. Dabei kommen sie aber auch zu Fragen wie "Ist Humor ein Social Skill?" oder "Kann man Social Skills einfach so lernen?". Selbst außerhalb der Rolle als PO ist es nicht schlecht sich seiner Social Skills bewusst zu sein, daher kann man viele Aspekte dieser Folge auch nutzen, um selbst mehr über die interaktion mit anderen Menschen nachzudenken. Quellen/Bücher: https://www.harvardbusiness.org/5-key-human-skills-to-thrive-in-the-future-digital-workplace/ Der KODE® KompetenzAtlas ( https://www.kodekonzept.com/wissensressourcen/kode-kompetenzatlas/ ) Empathie. In: Dorsch: Lexikon der Psychologie. Hogrefe Verlag, Göttingen 2017, ISBN 978-3-456-85643-8 Geoff Watts: Product Mastery ( https://www.inspectandadapt.com/product/product-mastery ) Roman Pichler: Leadership im Produktmanagement ( https://dpunkt.de/produkt/leadership-im-produktmanagement/ ) Relevante Podcast-Folgen: Wie kann ich mit mehr Präsenz als Product Owner auftreten? (mit Alexandra Klingor) https://produktwerker.de/mehr-prasenz-als-product-owner/ Herausforderungen zwischen Product Owner & Developer (mit Bernd Joussen) https://produktwerker.de/herausforderungen-productowner-developer/ …
Steffi Götten im Gespräch mit Dominique OKR als Methodik um Ziele zu setzen und zu verfolgen ist seit einigen Jahren auch bei uns in Deutschland in aller Munde. Daher, eigentlich schon lange überfällig, wollen wir uns auch mit dem Thema OKR beschäftigen und haben uns eine Expertin eingeladen, die langjährige Zuhörer*innen bereits kennen dürften. An der Seite von Dominique steht Stefanie Götten als Expertin und sie tauschen sich zum Thema mit einem klaren Fokus aus: Was bedeutet die Einführung von OKR für uns in unserer Verantwortung als Product Owner. Stefanie war bereits bei uns im Podcast zu Gast. In der Folge "Dein Freund der Scrum Master" ( https://produktwerker.de/dein-freund-der-scrum-master/ ) war sie schon einmal bei uns zu Gast. Mehr zu Stefanie findet ihr unter https://www.linkedin.com/in/stefanie-g%C3%B6tten/ . Welche Erfahrungen hast du rund um die Einführung und Nutzung von OKR gesammelt. Teilst du unsere Meinungen und Erfahrungen oder widersprichts du? Lass uns gerne daran teilhaben. Wir freuen uns, wenn du dein eigenes Verständnis mit uns in einem Kommentar hier oder auf unserer Produktwerker LinkedIn-Seite teilst. Und falls dir der Podcast gefällt, freuen wir uns auch immer über eine Bewertung in der von dir favorisierten Podcast-App.…
Dominique im Gespräch mit Oliver Fragt man drei Product Ownerinnen, was sie als ihre Verantwortlichkeit ansehen, so erhält man vier sehr unterschiedliche Antworten. In vielen Fällen ist eine Ursache für die Vielfalt der Rolleninterpretationen, dass manche als Product Owner im Scrum Kontext arbeiten und andere wiederum als SAFe Product Owner. Es ist also an der Zeit, dass Oliver und Dominique über die Gemeinsamkeiten und Unterschiede sprechen. Denn aus ihrer Perspektive ist es dieses Thema eines der großen Missverständnisse - ein Scrum PO ist etwas komplett anderes als ein SAFe PO. Und nachdem einige Beiträge und Meinungen in den letzten Wochen in die Timeline der beiden gespült wurden, auch ein guter Zeitpunkt die eigene Sichtweise zu konkretisieren. Dominique und Oliver starten mit einer Reflexion eines Beitrags von Roman Pichler zu "Six Types of Product Owner", der in diesem Podcast schon einmal in der einen oder anderen Episode zitiert wurde. Fokus legen beide aber auf den Scrum PO und den SAFe Product Owner. Wo liegen die Gemeinsamkeiten, welche Unterschiede findet man. Nach einem Blick in den Scrum Guide und in die detaillierteren Erläuterungen in SAFe wird auf die eine oder andere Äusserung von Kollegen referenziert, u.a. Sohrab Salimi oder Heiko Stapf. Natürlich artikulieren Oliver und Dominique auch sehr klar ihren eigenen Standpunkt und klären, dass auch in diesem Podcast sehr häufig der Scrum Product Owner im Mittelpunkt der Diskussionen steht. Wie immer schließt diese Episode mit einigen konkreten Tipps & Trick ab.…
Nam Hoang-Dong im Gespräch mit Tim Nam Hoang-Dong berichtet über seine Erfahrung als Product Leader einer Retained-Organisation im Gespräch mit Tim, d.h. wie sich die Steuerung eines großen externen Dienstleisters als Produktverantwortlicher anfühlt. Nam hat eine langjährige Erfahrung im Handel (MediaMarkt, ESPRIT, Thalia) und spricht in dieser Folge v.a. über die Zeit bei Esprit in die auch die agile Transformation des damaligen Dienstleisters fiel. Als Retained-Organisation wird dabei eine (meist) kleinere Einheit verstanden, die den beauftragten Dienstleister steuert. In der Praxis geschieht dies häufig nach Outsourcing-Prozessen. Hier im Beispiel vom Fashion-Händler ESPRIT wurde das ganze Online-Business über viele Jahre in dieser Form aufgebaut und betrieben. D.h. auch die (agile) Produktentwicklung des ESPRIT Onlineshops geschah auf diese Weise. Tim war damals auf der Seite des Dienstleisters im Einsatz und hat die Veränderung der Dienstleister-Beziehung daher aus anderem Blickwinkel beobachten können. Mit einigen Jahren Abstand kommt es somit zu einer interessanten Reflexion der Transformation. Aber auch die Frage, was Nam aus dieser Erfahrung an Learning in seine neue Rolle als IT-Verantwortlicher bei Thalia mitgenommen hat, spielen im Gespräch eine Rolle. In Summe ergibt sich also ein toller Erfahrungsbericht eines Product Leaders im Handelskontext aus dem sicherlich einige Impulse gezogen werden können. Folgendes Buch nennt Tim im Verlauf des Gesprächs: Robbin Schuurman/Willem Vermaak: 50 Arten, Nein zu sagen Im Zusammenhang mit dieser Podcast-Episode über die Arbeit als Retained-Organisation möchten wir euch auch nochmal diese älteren folgen im Kontext der Dienstleister-Zusammenarbeit als Herz legen: Zusammenarbeit mit einem externen Team vom Dienstleister Der Product Owner aus Sicht eines Dienstleisters Als Product Owner auf Seiten einer Agentur Wenn ihr mit Nam Hoang-Dong persönlich in Kontakt treten möchtet oder weitere Fragen an ihn habt, freut er sich über eure Anfrage bzw. Nachricht auf seinem LinkedIn-Profil . Welche Learnings habt ihr aus der Zusammenarbeit mit und Steuerung von Dienstleistern gezogen? Kennt ihr vielleicht auch solch ein Konstrukt einer Retained-Organisation? Lasst uns gerne an euren Erfahrungen, Tipps oder auch eurer Meinung teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite .…
Oliver im Gespräch mit Dominique Wer kennt sie nicht, die kleinen Life Hacks, die durch minimale Veränderungen das Leben ein klein wenig leichter machen sollen. Der Ansatz der Culture Hacks dient dazu die Kultur einer Organisation zu verändern, aber eben mit kleinen Schritten. Gleichzeitig beziehen sich Culture Hacks auf Veränderungen im informellen Bereich. Es geht eben nicht darum direkt eine neue Rolle, neue Meetings oder andere Formalismen einzuführen. Oliver und Dominique sprechen in dieser Folge über Culture Hacks, die nach ihrer Erfahrung gut auf die Kultur der Organisation einwirken können. Sie stellen aber auch heraus, dass Culture Hacks immer Experimente sind und kein Erfolgsversprechen mit sich bringen. Beispielsweise kann man versuchen die Kultur der Organisation mittels geteilter O-Töne der Menschen, die das Produkt benutzen, mehr Richtung Erlebnisorientierung zu bringen. Wenn Mitarbeitende durch viele Meetings keine Zeit haben sich zu einem allgemeinen PO-Austausch zu treffen, bietet sich vielleicht ein gemeinsames Mittagessen an. Oder man teilt seine persönlichen Gedanken über aktuelle Produktthemen häufiger per SMS, Instantmessaging oder Mail und versucht so Gespräche anzustoßen. Rund um das Thema Kultur haben wir noch ein paar weitere spannende Folgen für euch: Diversity in der Produktentwicklung ( https://produktwerker.de/diversity-in-der-produktentwicklung/ ) Die Relevanz von UX den eigenen Stakeholdern vermitteln ( https://produktwerker.de/die-relevanz-von-ux-vermitteln/ ) Auf Business oder Nutzer fokussieren als PO? ( https://produktwerker.de/business-oder-nutzer/ ) Falls ihr noch weitere Tipps habt, wie man mit kleinen Maßnahmen die Kultur deiner Organisation verändern kann, lasst es uns gerne wissen. Wie sind eure Erfahrungen und welchen Herausforderungen musstest ihr euch dabei stellen? Wir freuen uns, wenn ihr eure eigenen Sichtweisen mit uns in einem Kommentar hier oder auf unserer Produktwerker LinkedIn-Seite ( https://www.linkedin.com/company/produktwerker ) teilt.…
Ralph Jocham im Gespräch mit Tim Bei all den verschiedenen Skalierungsoptionen, die es heute gibt, scheint es, als gäbe es nur wenig Einigkeit darüber, wie man die Rolle des PO skalieren kann. Ralph Jocham, der Autor des Bestsellers "The Professional Product Owner" , ist nach einem sehr interessanten Talk auf dem Scrum Day 2022 mit dieser Thema bei Tim zu Gast im Produktwerker-Podcast. Ralph stellt fünf Delegationsmodelle für Product Owner vor, die unabhängig von den vorhandenen Skalierungsmöglichkeiten abgeleitet werden können. Je nach individuellem Kontext können diese Delegationsmodelle einzeln oder in Kombination eingesetzt werden. Nachdem die beiden in ihrem Gespräch noch einmal auf das grundsätzliche Verständnis für die Rolle des Product Owner eingehen, fokussieren sie sich anschließend auf das Thema Skalierung. Die zu diesem Zweck vorgestellten fünf Delegationsmodelle (5Ts) sind: Taktisches Delegationsmodell - lassen Sie andere dabei helfen, das Product Backlog und andere taktische Dinge zu verwalten Technisches Delegationsmodell - bauen Sie Ihre Arbeit in das Produkt ein Team-Delegationsmodell - delegieren Sie an die Teammitglieder, lassen Sie sie mit den Kunden sprechen Temp-Delegationsmodell - weisen Sie jedem Team einen Vertreter zu, bis die Teams autark sind Themen-Delegationsmodell - schaffen Sie Vertreter (SMEs) für verschiedene Produktbereiche, die die Teams konsultieren können Natürlich schließt auch diese Episode mit praktischen Tipps und Tricks unseres Gastes.…
Was in Dominiques Kopf gerade so vorgeht Mit dieser Folge wagen wir ein kleines Experiment. Einer von uns spricht über einen Gedanken, der ihn gerade umtreibt und erhofft sich mit euch in einen Dialog zu treten. Dazu seid ihr alle herzlich eingeladen auf die Seite dieser Folge zu gehen und in den Kommentaren eure Perspektive auf die Gedanken zu teilen. Hier könnt ihr mitmachen -> https://produktwerker.de/gedankenaustausch-was-kommt-nach-ux/ Dominique spricht diesmal über seine Gedanken, welche Gestaltungsaspekte nach der UX kommen können und wirft dabei einen Blick in eine mögliche Zukunft in 30 Jahren. Vor 30 Jahren war noch eher Usability und die Benutzbarkeit relevant. Aus der Usability hat sich dann im Laufe der Zeit die UX entwickelt. Für Produkte wurde die Metapher des Werkzeugs verwendet. Der Gestaltungsaspekt der UX ist aber auf das Erleben der Interaktion fokussiert und wir versuchen insbesondere ein positives Erleben zu erzeugen. Menschen haben jedoch bezogen auf die Interaktion mit Produkten oft eine Aneinanderreihung von Episoden der Nutzung und der Nicht-Nutzung. Die Summe dieser Episoden erzeugt bei Menschen ggf. eine Beziehung zum Produkt. Dominique ist davon überzeugt, dass nach wir uns von der reinen Nutzbarkeit hin zum Erleben der Interaktion bewegt haben und zukünftig noch stärker in die Gestaltung der Beziehungsebene bewegen werden. Es geht dann nicht mehr nur darum EIN positives Erlebnis, sondern eine Historie aus positiven Erlebnissen zu schaffen, die eine emotionale Bindung der ein oder anderen Art zwischen User und Produkt ermöglicht. Besonders durch Automaten, die viel natürlicher mit dem Menschen kommunizieren wird der Aspekt des Partners stärker. Selbstverständlich brauchen wir weiterhin UX als Gestaltungsaspekt. Ohne positive Nutzungserlebnisse schaffen wir keine positive Nutzerbeziehung. Genauso braucht ein gutes Nutzungserlebnis eine gute Benutzbarkeit. Was bedeutet das für die Ausarbeitung zukünftiger Verantwortlichkeiten? Wahrscheinlich wird mehr Fokus auf die User Journey außerhalb der einzelnen Nutzungsepisode gelegt. Es werden Fragen geklärt wie: Wie sollen Nutzer die Beziehung zu dem Produkt empfinden oder wie ermöglichen wir eine emotionale Bindung? Produkte werden so zu emotional aufgeladenen Artefakten des Lebens. Die mögliche Metapher ist dann der Partner und wir müssen uns klar haben, welche Werte und Prinzipien das Produkt in der Beziehung und nach außen vertritt. Auch müssen wir verstehen, was es besonders macht. Die Entwicklung einer Persönlichkeit des Produkts erfolgt durch Austausch, bzw. Interaktion. Es gibt im Buch Gamestorming eine gut dazu passende Übung (Pinocchio-Produkt-Übung). Stell dir vor, dein Produkt erwacht auf einmal zum Leben. Welchen Charakter hat es und wofür kämpft es? Hedonische Aspekte fließen wahrscheinlich stark in die Bildung der Beziehung ein. Eine Beziehung macht auch was mit einem selbst. Customer Relation und User Relation wirken stark auf einander ein, je nach Produkt. Die Beziehungsebenen werden einen Einfluss aufeinander haben. Hier wird sich aber im Laufe der Zeit eine Abtrennung der Fachdisziplinen entwickeln. Es werden aber auch Probleme durch die Fokussierung entstehen. Die Integration von UX als Gestaltungsaspekt in die Entwicklungsvorgänge von Organisationen ist im Moment auf breiter Flur zum Beispiel noch nicht abgeschlossen. Wie bei UX werden neue Fähigkeiten und Fertigkeiten gebraucht und nicht alle UX-Professionals haben diese bereits. Es wird eine Diffundierung der neue Fachdisziplin geben, die erst nach längerer Zeit konsolidiert werden wird. Jetzt aber genug von Dominiques Gedanken. Wie seht ihr das? Was ist eure Meinung? Teilt es mit allen unter https://produktwerker.de/gedankenaustausch-was-kommt-nach-ux/ .…
Oliver und Dominique im Gespräch Über die Zusammenarbeit von Product Ownern mit Stakeholder innen, Nutzer innen und so weiter haben wir schon mehrfach gesprochen. Aber immer wieder gibt es auch Kontexte, in denen wir als Product Owner mit anderen Product Ownern zusammenarbeiten. Diesen Kontexten begegnen wir insbesondere in größeren Organisationen, in denen mehrere Teams mit jeweils eigenen Product Ownern an einem großen Produkt zusammen arbeiten. Da werden große Produkte so geschnitten, dass verschiedene Product Owner gemeinsam mit ihren Teams Teil-Produkte verantworten. Aus der Skalierung mit mehreren Produktteams für ein Produkt ergibt sich in der Praxis häufig das ein oder andere Problem. Beispielsweise wirkt das Gesamtprodukt nicht mehr wie aus einem Guss, eben weil es auch von verschiedenen Menschen mit unterschiedlichen Sichtweisen entwickelt wurde. Wenn jedes Teil-Produkt sein eigenes (Teil-)Product Backlog hat, wird es mit der gemeinsamen Priorisierung kompliziert. Oft hängen auch die Metriken der jeweiligen Teil-Produkte nicht ganz sauber zusammen. Viele Probleme, die auch beim Zusammenarbeiten der Product Owner auftauchen und dort in irgendeiner Art gelöst werden sollen. Weitere spannende Folgen rund um das Zusammenarbeiten findet ihr hier: Als Product Owner im skalierten Umfeld Das Product Owner Team Habt ihr euch mit dem Thema schon mal beschäftigt? Wie geht ihr selbst damit um? Lasst uns gerne an euren Erfahrungen oder auch euren Herausforderungen teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite .…
Dominique und Oliver im Gespräch Biases sind Verzerrungen bzw. systematische Fehler in der Beurteilung von Information. Der bekannteste ist vielleicht der sogenannte "Cognitive Bias", eine kognitive Verzerrung. Letztlich beeinflussen sie unser Urteilsvermögen und durch subjektive Eindrücke und beeinflussen so auch Entscheidungen von Product Ownern. Objektivität wird somit erschwert, denn Menschen neigen dazu, alle Schlussfolgerungen zu akzeptieren, die in ihr Glaubenssystem passen, ohne diese gründlich zu hinterfragen. Umgekehrt neigen wir dazu, Behauptungen abzulehnen, die nicht in unser Glaubenssystem passen, auch wenn sie durchaus logisch sein könnten. Oliver und Dominique nehmen sich in dieser Folge dieses Phänomen aus der Verhaltenspsychologie mal vor, erklären es anhand von Beispielen und versuchen auch mal zu reflektieren, wie Product Owner in ihren Entscheidungen von so etwas betroffen sind. Weitere Biases, die in dieser Episode u.a. behandelt werden: Dunning Kruger Effekt = Tendenz von wenig kompetenten Menschen, das eigene Können zu überschätzen und die Kompetenz anderer zu unterschätzen Confirmation Bias = Neigung, Informationen so zu interpretieren, dass sie die eigenen Erwartungen einfach nur bestätigen Implicit Bias = das Produkt so bauen, wie man es sich selber wünscht bzw. vorstellt, d.h. von sich auf andere schließen IKEA-Effekt = die Neigung, selbst zusammengebauten Gegenständen im Vergleich zu fertig gekauften Massenprodukten mehr Wertschätzung entgegenzubringen. In Bezug auf Software: alles selber programmieren zu wollen, anstatt Standard-Software einzubinden Effort justification Bias = Wenn wir Aufwand in etwas investiert haben, wird es als wertvoller betrachtet, als wenn wir objektiv drauf schauen würden Verlustaversion = Die Tendenz, Verluste höher zu gewichten als Gewinne Und dies sind letztlich auch alles Fallen, in die wir als Product Owner reinlaufen können. Oliver und Dominique geben daher Tipps, was man gegen diese "Störenfriede" tun kann oder zumindest, wie man damit als Product Owner besser umgehen kann. Ein tolles Buch, was sich letztlich auch um das Thema der Biases dreht ist "Schnelles Denken, langsames Denken" von Daniel Kahneman (englischer Originaltitel: Thinking, Fast and Slow). Kahneman verfolgt anhand vieler Beispiele aus seiner Forschung die folgende These: es gibt zwei Arten des Denkens: Das schnelle, instinktive und emotionale System 1 und das langsamere, Dinge durchdenkende und logischere System 2. Zum Thema "Biases" passt auch diese frühere Folge aus diesem Podcast sehr gut: Decision Poker und Entscheidungsverfahren Kano-Modell um Kundenbedürfnisse zu verstehen Habt ihr euch mit dem Thema schon mal beschäftigt? Wie geht ihr selber damit um? Lasst uns gerne an euren Erfahrungen oder auch euren Herausforderungen teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite .…
Konstantin Diener im Gespräch mit Tim Product Discovery soll uns helfen Produktrisiken bei komplexen Problemstellungen frühzeitig zu erkennen und Lösungen zu finden, die von Nutzer:innen wertgeschätzt und nutzbar sind, während wir sie als Team bauen und wirtschaftlich betreiben können. Also lasst kontinuierliche Product Discovery und Delivery Hand in Hand einher gehen! Klingt dir zu theoretisch? Na, dann hör' dir mal das ganz praktische Problem von Konstantin Diener und seinen Leuten bei cosee an! In kürzester Zeit galt es, ein physisches Produkterlebnis wie die Essener Brettspiel-Messe SPIEL in eine digitale, Pandemie-gerechte Form zu übersetzen, die für Besucher:innen und Messeveranstalter gleichermaßen erfolgreich sein musste. Im Gespräch mit Tim liefert Konstantin einen lebhaften Erfahrungsbericht, wie ihnen das durch eine enge Verzahnung von Product Discovery und Delivery gelungen ist. Offensichtlich hätte das Team in diesem engen Zeitrahmen auch schlichtweg gar keine Zeit für eine vorgeschaltete Discovery oder Analyse-Phase gehabt. Also wurde das Problem zur Lösung: ultra-kurze Zyklen und kontinuierliches Nutzer-Feedback führten zu einer sehr gut funktionierenden Messe SPIEL.digital. Details zum besprochenen Projekt, die SPIEL.digital zu erstellen findet man direkt hier auf den Seiten von cosee und zudem ein sehenswertes Video mit einem Vortrag von Konstantin Diener über das gesamte Projekt der SPIEL.digital. Ein Interview aus Sicht von Product Owner und Scrum Masterin über das Projekt ist auch sehr spannend. Zudem gibt es einen Erfahrungsbericht zur Home Office Erfahrung von cosee gibt es bei ihnen im Blog. Konstantin nennt im Gespräch folgende Quellen: Teresa Torres: Continuous Discovery Habits Gojko Adzic: Specification by Example Julia Grace von Slack: Talk über Clarity Diese Folge steht auch mit den folgenden Episoden in einem engen Kontext rund um Product Discovery: Product Discovery in Scrum integrieren (mit Juliana Brell) Kontinuierliche Product Discovery in Teams etablieren (mit Jan Kiekeben) Outcome Goals und Product Discovery (mit Tim Herbig) Wie verbindet ihr Discovery und Delivery bei euch in der Produktentwicklung? Was sagt ihr zu diesem Erfahrungsbericht über die Digitalisierung der SPIEL? Was hat euch begeistert? Lasst uns gerne an euren Erfahrungen oder auch eurer Meinung teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite .…
Oliver und Tim im Gespräch Das Konzept "Geber, Nehmer oder Tauscher?" von Adam Grant hat's uns angetan. Oliver Winter und Tim Klein besprechen daher sein Buch "Geben und Nehmen - Warum Egoisten nicht immer gewinnen und hilfsbereite Menschen weiterkommen" (im Original: "Give and Take: Why Helping Others Drives Our Success"). Zunächst mal wird natürlich erläutert, was hinter der Idee von Adam Grant steckt und was Geber, Nehmer oder Tauscher sind. Neben dem Verständnis der einzelnen Verhaltens-Ausprägungen von Geber, Nehmer oder Tauscher sind einige Erkenntnisse besonders erstaunlich: so zerfallen die Geber in zwei unterschiedlich erfolgreiche Cluster - als Geber ist man also weder per se weniger erfolgreich noch in jedem Fall erfolgreicher als Nehmer oder Tauscher. Und warum sind die meisten Menschen im Privaten "Geber", aber im Berufsumfeld verhalten sich die meisten dann doch als Tauscher oder sogar als Nehmer? Anschließend geht's um die Frage, was dieses Konzept für Product Owner bedeuten kann. Kann man auch in der Product Owner Rolle als Geber erfolgreicher sein? Was ist, wenn man nur mit Nehmern oder Tauschern zusammenarbeiten muss? Insbesondere Adams Grants Empfehlungen zu "Powerless Communication" (siehe YouTube-Empfehlung) und der "5-Minuten-Gefallen" können Product Ownern aus Sicht von Tim und Oliver vermutlich sehr gut helfen. Das Buch hat Oliver und Tim sehr beeindruckt und beide sprechen daher eine ganz klare Lese-Empfehlung aus: Adam Grant: Geben und Nehmen - Warum Egoisten nicht immer gewinnen und hilfsbereite Menschen weiterkommen Weitere Empfehlungen: TEDx-Talk von Adam Grant zum Thema "The power of powerless communication" Blog-Artikel von Susan Cain "7 Ways to Use the Power of Powerless Communication" Diese Folge steht auch mit den folgenden Episoden in einem engen Kontext: Coaching Skills als Product Owner entwickeln (mit Daniel Hommel) Introvertiert als Product Owner - geht das? (mit Timon Royer) Kanntest du das Buch schon? Wie agierst du als Product Owner und unterscheidet es sich von deinem privaten Verhalten? Hast du "Powerless Communication" (vielleicht unbewusst) schon mal ausprobiert? Lasst uns gerne an euren Erfahrungen oder auch euren Herausforderungen teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite .…
Dominique und Tim im Gespräch An welchen Dingen scheitern Product Owner? Was kann alles im Weg stehen oder schief gehen? Welche Rahmenbedingungen schaden dem erfolgreichen Wirken von Product Ownern? Tim und Dominique haben eine ganze Reihe von Punkten zusammengetragen die Probleme bereiten können. Im Gespräch werden diese kritisch beleuchtet, z.T. werden Hintergründe und zu Grunde liegende Probleme besprochen. Herausgekommen ist eine Folge, bei der wir den Finger, besser gesagt beide Hände, mal tief in die Wunden organisatorischer, methodischer und auch persönlicher Unzulänglichkeiten legen. Sicherlich kann diese Episode daher gut zur Selbstreflexion dienen: Welche dieser Punkte trifft in meinem Kontext zu? Was habe ich auch schon erlebt? Wo kann ich selber noch Dinge verändern? Sicherlich treten viele dieser Herausforderungen oder Probleme nur vereinzelt oder in leicht abgewandelter Form auf, aber in irgendeiner Art und Weise haben wir Produktwerker diese Phänomene alle schon mal hier und da angetroffen. Tim und Dominique gucken zunächst auf den Bereich von Organisation und dem Kontext in dem die Produktentwicklung stattfindet. Als nächstes Cluster schauen sie sich alles an, was mit dem Zusammenspiel und der Kommunikation mit anderen zu tun hat (Stakeholder, Team, …). Danach geht es um das eigene Verhalten in der Product Owner Rolle, was je nach dem zu Problemen führen kann. Auch das eigene Rollenverständnis kann im Wege stehen. Und schließlich gehts noch um fehlendes Können, also mangelndes Wissen oder Ausbildung. Product Owner können also aus vielfältigen Gründen scheitern. Wir wünschen uns aber, dass ihr erfolgreich seid und wollen euch mit dieser Folge eine ganze Reihe von Warnhinweisen an den Wegesrand stellen, so dass ihr die Untiefen der eigenen Lernreise früh genug erkennen könnt. Quellen, die genannt werden: Blog-Artikel von Roman Pichler: Be a Balanced Product Leader, not a Feature Broker or Product Dictator Im Gespräch verweisen Dominique und Tim u.a. auch diese älteren Folgen unseres Podcasts, die super zum Thema "Woran scheitern Product Owner?" passen: Herausforderungen zwischen Product Owner & Developer Nein sagen als Product Owner Sind die PO bei euch gut unterwegs? Welche Bedingen machen es bei euch schwierig? Was meint ihr: woran scheitern Product Owner bei euch - oder sind früher vielleicht gestrauchelt, aber jetzt bekommt ihr es besser hin? Lasst uns gerne an euren Erfahrungen oder auch euren Herausforderungen teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite .…
Jan Kiekeben im Gespräch mit Tim Wie etabliert man eine kontinuierliche Product Discovery in den Produktteams? Jan Kiekeben, Discovery Coach bei XING, gibt im Gespräch mit Tim Einblicke in seine Arbeit. Herausgekommen ist ein interessanter Erfahrungsbericht. Zunächst klärt Tim mit Jan Kiekeben erstmal sein Verständnis von Product Discovery und Jan erzählt von seiner Lernreise, die ihn in diese Position geführt hat. Besonders spannend (und vielleicht auch mutig) ist auch die Art und Weise, wie Jan zu der Rolle gekommen ist. Hierzu teilt er auch seinen ganz persönlichen Tipp. Wie geht Jan das Coaching an? Warum schnappt er sich vor allem das sog. Product Trio? Wie geht er dabei in der Regel vor und wie lange begleitet er ein Team? Folgende Bücher werden in dieser Folge genannt: Marty Cagan - EMPOWERED: Ordinary People, Extraordinary Products Teresa Torres - Continuous Discovery Habits Michael Bungay Stanier: The Coaching Habit: Wie Sie mit Fragen führen und dabei das Potenzial Ihrer Mitarbeiter entfesseln Die empfohlene Masterclass von Teresa Torres findet ihr hier . Diese Folge steht in engem Zusammenhang zum Erfahrungsbericht von Juliana Brell zur ähnlichen Herausforderung bei sipgate: Product Discovery in Scrum integrieren . Weitere Content-Empfehlungen gibt's bei uns in der Produktwerker Box ( produktwerker.de/box ). Dort gibt's zur Herausforderung Product Discovery eine Menge von uns ausgewählten und empfohlenen Content: Product Discovery um Wissen zu generieren Ihr könnt gerne Kontakt zu Jan Kiekeben aufnehmen. Er freut sich über den Austausch zur Implementierung von kontinuierlicher Product Discovery in Produktteams. Ihr erreicht Jan am Besten via XING ( https://www.xing.com/profile/Jan_Kiekeben/ ) oder per LinkedIn ( https://www.linkedin.com/in/jan-kiekeben/ ). Probiert ihr auch bereits, in euren Teams kontinuierliche Product Discovery zu etablieren? Wenn ja, wie macht ihr das? Wenn nein, woran hapert es noch? Lasst uns gerne an euren Erfahrungen oder auch euren Herausforderungen teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite .…
D
Die Produktwerker
Tim, Dominique und Oliver im Gespräch Product Principles sind ein wertvolles Instrument in der Entwicklung von Produkten. Sie sind Grundsätze, die als Kompass bei Produktentscheidungen helfen. Sie helfen uns Entscheidungen effektiv und effizient zu treffen. Wir klären anfänglich woher das Thema eigentlich kommt, stürzen uns dann aber direkt darauf wie Product Principles eigentlich aussehen. Eine Form, die uns besonders hilft ist beispielsweise A über B: Der mobile Kontext ist uns wichtiger als Desktop oder Hotelgäste sind wichtiger als Hotels. Anschließend tauschen wir uns noch dazu aus, wie wir Produktprinzipien gut entwickeln können. Oft gibt es sie schon, allerdings nicht explizit. Wenn ihr euch noch weiter mit dem Thema beschäftigen wollt, empfehlen wir euch folgende Quellen: Applying Product Principles to Guide Better Product Decisions von Nir Gazit ( https://www.mindtheproduct.com/applying-product-principles-guide-better-product-decisions/ ) How to create product principles that make a difference von Mal Sanders ( https://productcoalition.com/how-to-create-product-principles-that-make-a-difference-a8d7cd59bdd0 ) Wir haben schon über ähnliche Themen gesprochen. Wenn ihr euch hier mehr vertiefen wollt, empfehlen wir euch folgende Folgen: Warum Product Owner die Unternehmensvision kennen sollten ( https://produktwerker.de/unternehmensvision/ ) Eine Produktstrategie entwickeln ( https://produktwerker.de/produktstrategie-entwickeln/ ) Wie die Produktvision hilft, Product Ownern eine Richtung zu geben ( https://produktwerker.de/wie-die-produktvision-hilft-product-ownern-eine-richtung-zu-geben/ ) An der Stelle möchten wir uns übrigens bei den Teilnehmenden unserer Session zu "Product Principles" auf der Agile Cologne ( https://agilecologne.de/ ) am 10. Juni 2022 bedanken. ihr habt uns wertvolle Impulse gegeben! Und wenn ihr eigene Erfahrungen mit Product Principles gemacht habt, teilt sie gerne mit allen bei uns in den Kommentaren -> https://produktwerker.de/product-principles/ .…
Dennis Willkomm im Gespräch mit Oliver In dieser Episode ist Dennis Willkomm unserer Gast und Spricht mit Oliver über das Produkt Buch. Genauer gesagt handelt es sich um einen Erfahrungsbericht zum Buch schreiben. Und da es sich bei dem betrachteten Werk um Dennis erste Veröffentlichung handelt und er quasi als Product Owner für ein Buch agiert hat, diskutieren die beiden spannende Learnings, die unserer Meinung nach auch auf dein Produkt übertragen werden können. Dennis erklärt anhand der im Produktmanagement verbreiteten Praktiken - Product Vision, Product Roadmap, Product Backlog - wie "agil" er an die Herausforderung herangegangen ist. Natürlich spielen auch die Scrum Events wie Sprint Review und Sprint Retrospektive eine gewichtige Rolle in dem Gespräch. Zu Abschluss erklärt Dennis, was er aus der Erfahrung Product Owner für ein Buch zu sein gelernt hat und was er beim Schreiben seines zweiten Buches anders machen will. Dennis Buch " Roadmap durch die VUCA-Welt: Für Führungskräfte, Scrum Master und Agile Coaches " ist im Oktober 2021 bei UVK erschienen. Aus unserer Sicht ist das Buch ein wirklich beeindruckendes Nachschlagewerk, welches u.a. die Themen "Von der Industrialisierung zur Digitalisierung", "Der Mensch im Mittelpunkt", "Das Team als treibende Kraft", "Führung in Veränderung" und "Denken, fühlen und handeln für die Welt von morgen" intelligent erläutert.…
Oliver und Dominique im Gespräch Nachdem wir bereits über die agilen Schätzmethoden Magic Estimation und Planning Poker in vorherigen Podcastfolgen gesprochen haben, geht es in dieser Episode um NoEstimates. Dominique und Oliver sprechen darüber, warum sie auch "Nicht-Schätzen" in diese Reihe der Praktiken einordnen. Statt beispielsweise mit der Fibunacci-Reihe zu agieren werden bei NoEstimates in der Regel die Anzahl der Items gezählt und so Prognosen anhand von historischen Daten erstellt. Dominique und Oliver schauen auf die grundsätzlichen Schwierigkeiten, sofern ich als Product Owner mit Schätzungen arbeite. Sie diskutieren die eine oder andere Dysfunktion und die Gefahr, sich zu sehr auf Fristen und Product Delivery zu konzentrieren. Nachdem so die Motivation sich mit NoEstimates zu beschäftigen geklärt ist, geht es im Kern der Folge um die Voraussetzungen, die ich schaffen muss. Und natürlich werfen Oliver und Dominique auch einen kritischen Blick auf Schwierigkeiten, die bei dieser Methode aufkommen kann. Wie immer runden persönliche Tipps aus dem eigenen beruflichen Werdegang diese Episode ab. Dominique empfiehlt folgende YouTube-Videos für einen Einstieg in das Thema: NoEstimates - Vasco Duarte NoEstimates - Allen Holub…
Timon Royer im Gespräch mit Tim Tims Gast in dieser Folge ist Timon Royer, Product Owner und Co-Host des Podcast „Still & Stark - der Podcast für leise Menschen mit innerer Stärke“ . Das Thema dieser besonderen Episode „Introvertiert und Product Owner - wie geht das?“ Zunächst definieren Timon und Tim die Begriffe Introvertiertheit und Schüchternheit, denn diese werden trotz großer Unterschiede im Alltag oft synonym verwendet. Timon erklärt, was bei Introversion im Gehirn passiert und was das mit dem Dopaminspiegel zu tun hat. Grundsätzlich sei es wichtig, sich und seine Bedürfnisse selbst erkennen zu lernen, trotz der sozialen Erwartungshaltung und Glaubenssätze, die schon früh geprägt wurden. Im zweiten Teil des Gesprächs gehen die beiden dann auf konkrete Herausforderungen für Introvertierte in der Product Owner Rolle ein. Timon zeigt anhand konkreter Beispiele, dass es wichtig ist, auf die eigene Energie zu achten und im eigenen Umfeld eine Transparenz über die eigenen Bedürfnisse herzustellen. Explizit gucken Tim und Timon auf die Events Sprint Review und Sprint Retrospektive und auf die Zusammenarbeit mit Stakeholdern. Denn auch introvertierte Product Owner müssen und können führen. Besonders wichtig ist es, Kompetenz auszustrahlen. Und oft kann man die eigene Introversion zur Stärke nutzen, denn wenn man etwas sagt, dann hat man auch nachgedacht. Wie immer schließt die Folge mit Tipps ab, wie du dich in das Thema vertiefen kannst.…
Dominique und Tim im Gespräch Wie wir als Product Owner die Produktvision in unserem eigenen Kontext erfolgreich einbinden war bereits ein Thema in unserem Podcast. In dieser Folge wollen wir verstehen in welcher Art und Weise die Unternehmensvision für unsere Arbeit als Product Owner relevant ist. Daher sprechen in dieser Folge Tim und Dominique darüber, wie Product Owner die Unternehmensvision in unserer Arbeit integrieren können. Dabei streifen die beiden nicht nur die leidliche Frage wodurch sich eine Vision von einer Mission unterscheidet, sondern auch welchen Einfluss eine solche Vision/Mission für die Entwicklung eines Produktes spielt. Besonders relevant wird die Unternehmensvision beispielsweise wenn mehrere Produkte aus ihr abgeleitet werden. Selbst bei Unternehmen, bei denen es scheint, dass nur ein Produkt existiert (z. B. Instagram) existieren doch meist mehrere Produkte (Instagram für Unternehmen, Instagram für Werbetreibende usw.). Auch zeigen Dominique und Tim auf, dass es hilfreich wäre, die Unternehmensvision in regelmäßigen Abständen im Rahmen des Plannings und des Reviews allen Beteiligten noch einmal in Erinnerung zu rufen. Alleine schon die Frage, in welcher Art und Weise das eigene Produkt bzw. der Wertzuwachs im letzten Sprint auf die Unternehmensvision einzahlt, kann durchaus erhellend sein. Hier stellt sich dann auch die Frage, durch welche Kennzahlen wir unseren Fortschritt in Richtung Produktvision erkennen und wir begründen können warum das auch zu Erreichung der Unternehmensvision wertvoll ist. Am Ende bleibt vor allen ein Appell an alle Product Owner, dass wenn sie die Unternehmensvision nicht kennen, sie diese in Erfahrung bringen sollten. Das Produkt mit seiner Vision sollten wir nämlich in die Unternehmensvision eingliedern. Übrigens haben wir uns zum Thema Produktvision schon einige Inhalte zusammengesucht. Ihr findet sie unter https://produktwerker.de/herausforderung/produktvision-erstellen/ . Die Folge zur Produktvision findet ihr unter https://produktwerker.de/wie-die-produktvision-hilft-product-ownern-eine-richtung-zu-geben/ .…
Alex Kylburg im Gespräch mit Tim Konflikte zwischen Scrum Master und Product Owner gibt es wahrscheinlich in jedem Team. Immer dann, wenn Menschen mit unterschiedlichen Verantwortlichkeiten zusammenarbeiten, werden sie in eine Meinungsverschiedenheit laufen. Dies muss nicht immer ein einen Konflikt münden. Sofern aber unterschiedliche Vorstellungen über die andere Rolle existiert, kann es herausfordernd sein, diesen Dissenz aus der Welt zu räumen. Zum Thema Konflikte zwischen Scrum Master und Product Owner ist in dieser Podcastfolge Alexander Kylburg von der paragrah eins GmbH aus Köln bei Tim zu Gast. Alex ist ein Urgestein der agilen Community in Köln und u.a. Mitausrichter der Agile Cologne. In dieser Folge teilen die beiden konkrete Situationen, in denen es zu Konflikten gekommen ist. Spannend ist die Diskussion, ob diese Konflikte notwendig sind und was passiert, falls es zu viel Harmonie im Scrum Team gibt. Alexander geht möglichen Ursachen genauer auf den Grund und sieht als einen Grund für Dissenz, wenn der Product Owner oder sogar die Organisationen den Wertnicht sieht, den die Scrum Masterin zum Produkterfolg beiträgt. Ein weiterer Schwerpunkt der Folge liegt auf den Umgang mit solchen Situationen. Hier kann eine neutrale Moderation zwischen den beiteiligten Personen oder Coaching sicher ein erster Ansatz sein. In dem Zusammenhang sei auf die Leistungen von paragraph eins verwiesen, die Alex in der Episode erwähnt: Mentoringprogramm für Scrum Master Intervision für Scrum Master…
Oliver und Dominique im Gespräch Planning Poker ist ein weit verbreitete Technik, wenn es darum geht im agilen Kontext zu schätzen. Dabei kann ein Team durch gemeinsames Schätzen und einem gezielten Austausch von Argumenten sich nach und nach ein gemeinsames mentales Modell erarbeiten. Schätztungen, die so entstehen werden anschließend zur Priorisierung und Planung eingesetzt. Die Grundlage für Planning Poker bildet im Grunde eine Technik namens Breitband-Delphi, bei der auch mehrere Experten zusammen ein Urteil abgeben und sich zwischen ihren individuellen Aussagen abstimmen dürfen. In dieser Folge besprechen Oliver und Dominique welche Rolle die Technik für Product Owner hat und an welchen Stellen sie vielleicht noch wertstiftend eingesetzt werden kann. Nach der Klärung, woher die Technik eigentlich kommt sprechen die beiden über den konkreten Ablauf und mögliche Einsatzzwecke. Außerdem denken die beiden auch darüber nach, welche Vor- und Nachteile die Technik hat. Gerade um die Nachteile sollten Product Owner wissen, damit sie mit den Ergebnissen einer solchen Schätzung umgehen können bzw. wissen an welchen Stellen Ergebnisse vielleicht auch mal hinterfragt werden sollten. Oliver und Dominique schließen wie immer mit einigen Tipps, die ihrer Erfahrung nach dabei helfen noch ein wenig mehr aus der Planung mittels Planning Poker herauszuholen. Im Gespräch wird auf folgende anderen Folgen verwiesen: Agiles Schätzen: Magic Estimation ( https://produktwerker.de/magic-estimation/ ) Folgende Referenzen finden wir in dem Kontext wertvoll: The Original Paper ( https://wingman-sw.com/articles/planning-poker ) Planning Poker auf der Website von Mountain Goat Software ( https://www.mountaingoatsoftware.com/agile/planning-poker ) Darüber hinaus empfiehlt sich bei Gelegenheit ein Blick in das Buch "Agile Estimating and Planning" von Mike Cohn, auch wenn es mittlerweile an einigen Stellen etwas in die Jahren gekommen ist.…
Felix Stein im Gespräch mit Oliver Thema dieser Podcast Folge sind die Herausforderungen von Product Ownership im Konzernumfeld. Wir arbeiten heraus, was die Arbeit eines PO im Konzern von einem PO in einem kleineren Unternehmen bzw. Startup unterscheidet. Felix Stein , Geschäftsführer der Agile Process GmbH aus Bonn, diskutiert diese Fragen im Gespräch mit Oliver. Felix stellt zu Beginn der Episode sein Verständnis von Product Ownership vor. Darauf aufbauend überlegen die beiden Gesprächspartner, was im Konzern für Voraussetzungen für Product Owner erfüllt sein sollten. Sie behandeln dabei die Themen Projekt- & Produktfokus, Entscheidungskompetenz, Fokus und Regulierungsherausforderungen. Eine Besonderheit für einen PO im Konzern liegt sicher darin, dass viele Produkt für interne Kunden entwickelt werden. Die Chancen und Risiken, auch für die Product Discovery, werden von Felix und Oliver intensiv beleuchtet. Gegen Ende der Podcastfolge geben Felix und Oliver praktische Tipps und Tricks für Produktorganisationen und Product Owner in Konzernen. Und stellen heraus, dass es durchaus einige Vorteile gibt, als PO im Konzern zu arbeiten. Denn hier kann ich auf zahlreiche Ressourcen zurückgreifen und von den anderen Product Ownern lernen.…
Oliver & Dominique im Gespräch Als Product Owner stehe ich sehr oft vor der Herausforderung, die unterschiedlichen Interessen von vielen Stakeholdern bei der Entwicklung von Features meines Produktes zusammenzubringen. Hier besteht die Gefahr, zu kleinteilig über einen von allen akzeptierten, machmal aber sogar "faulen" Kompromiss zu kommen. Eine Option dieser Falle zu entkommen, ist der von Shreyas Doshi vorgeschlagene CEO-Test. Dominique und Oliver diskutieren in dieser Podcast Episode, wann wir als Product Owner in diese Falle laufen. Und warum es gefährlich ist, erst in einem Sprint Review zu merken, dass der realisierte Kompromiss aus Sicht der Nutzer und des Unternehmens zu kurz oder sogar in die falsche Richtung gedacht ist. Shreyas schlägt für solche Situationen vor, einen Perspektivwechsel einzunehmen und auf den vereinbarten Konsens aus der Sicht des CEO zu gucken. Das Vorgehen ist eine wirkungsvolle Abkürzung, damit wir als Product Owner präventiv größer denken, unsere Einschränkungen hinterfragen und insgesamt mehr Überzeugung bei den Kompromissen gewinnen können, die wir am Ende eingehen. Der CEO-Test funktioniert folgendermaßen: Stellen wir uns vor, wir würden die gleichen Argumente für den Kompromiss gegenüber dem CEO vorbringen. Dass wir hier kein besseres Kundenerlebnis schaffen können, weil wir mit den Einschränkungen X, Y, Z konfrontiert sind. Wie klingt dieses Argument für uns? Glauben wir, dass wir uns in dieser Sache durchsetzen können? Wenn wir den CEO-Test anwenden, lautet die Antwort oft: "Hmm… eigentlich sind wir uns nicht sicher, denn wir wetten, dass der CEO A, B, C sagen wird." "Aha. Warum gehen wir also nicht davon aus, dass dieser Dialog bereits stattgefunden hat, und warum gehen wir nicht auf A, B, C ein, bevor wir uns auf diesen Kompromiss einigen?" Wie in jeder Podcastfolge geben Dominique und Oliver hilfreiche Tipps und Tricks aus ihrer eigenen Praxis als Product Owner. Ihre Impulse drehen sich vor allem um Kommunikation, denn als PO bin ich immer auch Geschichtenerzähler, und das in unterschiedlichen Zeithorizonten und Flughöhen. Und auch daher kann es sinnvoll sein, mit dem CEO-Test explizit die Perspektive des Geschäftsführers einzunehmen.…
Peter Rochel im Gespräch mit Tim Mit der "Jobs-to-Be-Done"-Theorie (JTBD) lassen sich unterschiedliche Dimensionen von Kundenbedürfnissen wunderbar erklären. So kann man schön unterscheiden, welche Bedürfnisse das Produkt oder ein Service bedient. Oder, um es im Wording der Jobs-to-Be-Done Theorie zu sagen: für die Erledigung welchen Jobs dieses Produkt vom Nutzer beauftragt wird. Unser Gast Peter Rochel ist zusammen mit Eckhart Böhme sicherlich das führende Gespann, das es im deutschsprachigen Raum rund um die JTBD-Theorie gibt. Aber die beiden halten sich nicht mit der Theorie auf, sondern nutzen sie in ihrer praktischen Innovationsarbeit und Produktentwicklung. Und genau darum geht diese Podcast-Folge. Zunächst erklären wir natürlich erst noch mal Herkunft, Aufbau und Idee der Jobs-to-Be-Done Theorie. Aber dann geht es vor allem um die Anwendungen in den sogenannten JTBD-Interviews. Beispiele solcher Interviews könnt ihr im Podcast "Innovate+Upgrade" von Peter Rochel auch mal komplett anhören - echt spannend. Und im letzten Teil stellt Peter auch noch dass von ihm und Eckhart entwickelte spannende " Wheel of Progress® " vor. Das ganze ist ein super hilfreicher Canvas, um die JTBD-Interviews sehr strukturiert dokumentieren zu können. So macht man z.B. alle Kräfte, den jeweiligen Kontext und den dem Produkt (oder Service) zugeschriebenen erstrebten Fortschritt explizit. Wertvolle Quellen rund um "Jobs-to-Be-Done": JTBD.de – die deutschsprachige Community für die Jobs to Be Done (JTBD)-Theorie, inkl. einer guten Erklärung der JTBD-Theorie Clayton M. Christensen: Besser als der Zufall: "Jobs to Be Done" - die Strategie für erfolgreiche Innovation (Original: Competing Against Luck) Das Original-Video zum bekannten "Milkshake"-Beispiel von Clayton M. Christensen Shot: Was ist ein JTBD? (Kurzerklärung). Alle Shots gibt's hier Webinar von Peter Rochel bei Mr. Kundenbrille Kompakte Beispiele zu JTBD-Kundeninterviews im Podcast-Format Wenn ihr Peters Aktivitäten weiter verfolgen, direkten Kontakt zu Peter Rochel aufnehmen wollt oder er euch in euren Innovationsherausforderungen helfen kann, geht das für zahlreiche Wege: Web, Facebook, Twitter, LinkedIn, Xing oder per Mail. Kanntet ihr "Jobs-to-Be-Done" schon oder und nutzt ihr sogar schon JTBD-Interviews? Oder wie kommt ihr den wahren Kundenbedürfnissen ansonsten auf die Schliche? Lasst uns gerne an euren Erfahrungen oder auch eurer Kritik teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite .…
Tim im Gespräch mit Oliver Was unterscheidet eigentlich gute Product Owner von sehr guten Product Ownern? Welche Fähigkeiten und Fertigkeiten zeichnen die sehr guten Product Owner aus? Oder sollte man diese Fragen erst gar nicht stellen, weil es keine zufriedenstellende Antwort darauf geben kann. Tim und Oliver wagen die Fragen trotzdem zu stellen. Sie versuchen in dieser Podcastfolge vor allem auf die Human Skill und Fähigkeiten sehr guter Product Owner zu schauen. Die beiden beleuchten neben ganz grundsätzlichen Aspekten wie Haltung, Werte, Empathie auch den organistatorischen Kontext, in dem diese Aspekte unterschiedlich bedeutsam sind. Auf diesen einleitenden Gedanken aufbauend vertiefen Oliver und Tim ihr Gespräch vor allem in den Themenschwerpunkten Kommunikation, Umsetzung, Forschung und Organisation. Das Resultat sind viele kleine Impulse, die dich deine eigene Einstellung und Verhalten in der eigenen Product Owner Rolle sicher reflektieren lassen. Von uns in dieser Podcast-Folge erwähnte Quellen: Product Management in practice - Matt LeMay Geben & Nehmen - Adam Grant Strong Product People - Petra Wille…
Dominique im Gespräch mit Michael Schopp Diese Folge bietet dir wieder einen interessanten Erfahrungsbericht. Unser Gast Michael Schopp spricht mit Dominique über seinen Werdegang vom Product Owner zum Steuerberater, also - verglichen mit unseren bisherigen Gästen - einer eher untypischen Laufbahn. Michael beschreibt, wie er Product Owner wurde, warum ihn das damals reizte und was er aus dieser Zeit für seine jetzige Selbstständigkeit mitgenommen hat. Michael gibt uns einen tieferen Einblick, wie Produkte für Steuererklärungen erzeugt werden und welche Herausforderungen dabei existieren. Darüber hinaus berühren die beiden vor allem die Aspekte der Kundenorientierung und der Führung. Heute ist Michael Inhaber der Steuerberatung Schopp ( https://steuerberatung-schopp.de) . Wenn auch ihr mal Lust habt von euren ungewöhnlichen Werdegang zum Product Owner und darüber hinaus zu berichten, wendet euch gerne an uns (info@produktwerker.de). Außerdem freuen wir uns über Feedback von euch. Gerne auch im Podcatcher eurer Wahl.…
Dominique im Gespräch mit Oliver In dieser Folge unseres Product Owner Podcast sprechen Dominique & Oliver über die agile Praktik Magic Estimation. Und natürlich legen sie den Fokus ihrer Diskussion auf den besonderen Nutzen dieser Schätzmethode für Produkt Owner. Die Idee geht ursprünglich auf einen Vorschlag von Lowell Lindstrom aus dem Jahr 2008 zurück. Er nannte seine Idee „Affinity Estimation“. Boris Gloger griff den Ansatz auf und überarbeitete diesen zu Magic Estimation. Das Magische: sehr viele Product Backlog Items in sehr kurzer Zeit durchschätzen, um beispielsweise für ein bestimmtes Release eine grobe Idee zu einem Termin abgeben zu können. Dominique erläutert, wie er eine solche magische Schätzsession vorbereitet und dann mit dem Team durchführt. Er teilt viele hilfreiche Tipps und Tricks, die auch die Aufgaben eines Product Owners nach einer solchen Session betreffen: Wir überführe ich die Schätzungen ins Product Backlog? Und warum macht es Sinn, die Ergebnisse der Schätzungen im Product Backlog besonders zu markieren? Links zu Artikeln, um das Wissen zu vertiefen: Affinity Estimation Estimation: A kind of magic Magic Estimation (2010)…
D
Die Produktwerker
Peter Beck im Gespräch mit Oliver Als Scrum Product Owner nutze ich das Scrum Framework, um ein möglichst erfolgreiches Produkt zu entwickeln. Was ist aber mit dem dritten Teil „Owner“ konkret gemeint? Über diese Frage und damit auch die Rechte und Pflichten von Product Ownership spricht Peter „Pit“ Beck von Das Scrum Team mit Oliver in dieser Folge unseres Podcast. Pit erklärt Ownership mit der „Fähigkeit, den Besitz zu verwalten“. Also sollte ein Scrum Product Owner die Interessen des Besitzes wahren und im Sinne der Eigentümer handeln. Leider sind wir von diesem Verständnis in großen Organisationen und Konzernen meistens sehr weit entfernt. Rückhalt für POs aus der unternehmerischen Führung heraus ist eher in kleinen Unternehmen und Startups zu finden. Oliver und Pit diskutieren, wie weit die Ownership sinnvollerweise ausgestaltest sein sollte, damit der Product Owner auch wirklich erfolgreich sein kann. Einen weiteren Schwerpunkt legen die beiden auf Haltung und Fähigkeiten, die es braucht, um unternehmerisch tätig zu werden und das unternehmerische Denken auch ins Team zu bekommen. Diese Verantwortung muss man aber auch voll, aushalten können. Denn Ownership verpflichtet. Mit dem Eigentum kommen Macht und Verpflichtung, mit der ich nicht alles machen kann. Product Owner haben besondere Rechte und Pflichten. Daher sollte auch jede(r) selber eine bewusste Entscheidung treffen, ob man für die Übernahme bereit ist und diese auch will. Neben Tipps & Tricks reflektieren Pit und Oliver, wie es gelingen kann, mehr Product Owner mit wirklicher Ownership entwickeln zu können.…
D
Die Produktwerker
Dominique & Tim im Gespräch Wenn es Zeit wird den eigenen Kontext zu wechseln, dann müssen wir meist unser Produkt an jemanden übergeben. In dieser Folge beschäftigen sich Dominique und Tim damit, was es bei der Übergabe der Produktverantwortung an nachfolgende Product Owner zu beachten gilt und wie man dabei nach ihrer Erfahrung nach gut vorgehen kann. In der Folge verweisen wir auf zwei andere Folgen. Für Bessere Entscheidungen dun Delegation verweisen wir auf die Folge zum Decision Poker ( https://produktwerker.de/entscheidungen-treffen-decision-poker/ ) und natürlich dürfen wir nicht vergessen, dass uns bei der Übergabe auch der Scrum Master / die Scrum Masterin helfen kann ( https://produktwerker.de/dein-freund-der-scrum-master/) . Wie immer freuen wir uns über eure Erfahrungen und Tipps, wie man die Verantwortung als Product Owner am besten übergeben kann. Gerne auch Erfahrungen, wie es überhaupt nicht funktioniert… also außer ganz auf eine Übergabe zu verzichten. ;-)…
Helen Sedlmeier im Gespräch mit Tim Gerade zu Beginn einer Produktentwicklung ist die Unsicherheit über das "Was", das "Wie" und den Produktkontext oft unklar und unsicher - jedenfalls dann, wenn wir Produkte in einem komplexen Problemumfeld entwickeln. Hier setzt das sogenannte "Inception Deck" an. Die Vorlage gibt eine Struktur, um gemeinsam die Ausgangslage, den bislang verstandenen Nutzer- und Kundenbedarf zu beschreiben und somit ein gemeinsames Verständnis der Herausforderung explizit zu machen. Letztlich ist dies auch die Aufgabe des/der Product Owner:in hier für Klarheit zu sorgen. Oder anders gesagt: das Inception Deck kann gerade beim Start einer Produktentwicklung einen guten Rahmen für ein gelungenes Erwartungsmanagement schaffen. Und so etwas hilft der PO Rolle in der weiteren Arbeit mit Stakeholdern natürlich sehr. Alleine weil man sich in aufkommenden Diskussionen immer auf die gemeinsam im Inception Deck erarbeitete und zum aktuellen Zeitpunkt "gültige" Sicht berufen kann. Sicherlich ist auch das nur der "letzte Stand unseres Irrtums". Konkret besteht das Inception Deck aus einer Vorlage von zehn Fragestellungen, die gemeinsam besprochen oder erarbeitet werden sollten, bevor man in die Product Delivery Phase der operativen Umsetzung startet - oder zumindest sollte dies parallel gleich am Anfang geschehen. Die ersten fünf Fragen drehen sich um das "Wozu machen wir das?" („Why"), die Schritte sechs bis zehn um das "Wie machen wir das?" („How"). Im Gespräch erläutert Helen Sedlmeier die einzelnen Punkte und erklärt auch, wie sie das Inception Deck einsetzt und wie es für sie selbst, insbesondere als Externe Product Ownerin, besonders hilfreich ist. Die Vorlage selbst gibt es als PowerPoint Template – zu finden auf The Agile Warrior . Zum Thema Inception Deck hat Helen folgende Quellen empfohlen: Artikel von Helen im Mayflower Blog Neal Ford, Rebecca Parsons, Patrick Kua: Building Evolutionary Architectures: Support Constant Change Jonathan Rasmusson: The Agile Samurai - How Agile Masters Deliver Great Software Im Zusammenhang mit dieser Episode möchten wir euch auch diese Folgen ans Herz legen: Wie die Produktvision hilft, Product Ownern eine Richtung zu geben Welche Aufgaben gehören zur Product Owner Rolle? Wenn ihr weitere Fragen zum Inception Deck oder zu anderen Themen an Helen Sedlmeier habt, erreicht ihr sie am Besten über das LinkedIn-Profil von Helen . Sie freut sich über eure Kontaktaufnahme. Kanntet und nutzt ihr das Inception Deck vielleicht sogar schon? Oder wie klärt ihr das mit dem Erwartungsmanagement im Umfeld - gerade zum Beginn eurer Produktentwicklung? Lasst uns gerne an euren Erfahrungen oder auch eurer Kritik teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite .…
Dominique & Oliver im Gespräch „Nein sagen ist eine Kernkompetenz eines jeden Product Owners.“ Diese Aussage wird häufig wie ein Mantra unreflektiert wiederholt und an uns Produkt Owner kommuniziert. Oliver und Dominique versuchen in dieser Folge unseres Product Owner Podcast einmal kritisch auf die Aussage zu gucken. Und die beiden nähern sich generell der Herausforderung des Neinsagens. Nachdem Oliver & Dominique sich darüber ausgetauscht haben, ob und warum Nein sagen wichtig ist, teilen die beide Situationen aus ihrer eigenen Historie, in denen das Wort ihnen persönlich schwer gefallen ist. Intensiv reflektieren sie, was man bei einer Ablehnung von Wünschen oder Features beachten sollte und welche Arten von Nein sagen unterschieden werden können. Spannend ist der Gedanke, ob wir als Produkt Owner nicht viel mehr über das JA sagen nachdenken sollten. Dann zu oft Nein zu kommunizieren ist evtl nur ein Umweg zu mehr Fokus und es kann einem auf Dauer auch emotional nicht gut tun. Wie in jeder Folge, schließen Dominique & Oliver mit Tipps und Tricks das Thema ab.…
Welkom op Player FM!
Player FM scant het web op podcasts van hoge kwaliteit waarvan u nu kunt genieten. Het is de beste podcast-app en werkt op Android, iPhone en internet. Aanmelden om abonnementen op verschillende apparaten te synchroniseren.