Die Produktwerker

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

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/