Die Produktwerker

Oliver im Austausch mit Tim In dieser Folge tauschen sich Tim und Oliver zu agilen Praktiken aus. Sie geben dabei Einblicke in ihre persönliche Vorlieben: Welche agile Praktiken funktionieren? Und welche funktionieren für sie nicht? Tim und Oliver teilen, welche Tools sie in ihren Werkzeugkoffer packen, um ihrer Verantwortung als Product Owner gerecht zu werden. Diese Folge ist ein wilder Ritt von der Produktvision bis hin zum Product Backlog. Dabei wird auf eine ganze Reihe von früheren Podcast-Folgen Bezug genommen: Wie die Produktvision hilft, Product Ownern eine Richtung zu geben Agile Product Roadmaps Story Mapping nutzen, um über Outcome zu sprechen Das Product Goal und seine Bedeutung für Product Owner Dein Freund der Scrum Master Oliver erwähnt das Buch Continuous Discovery Habits (von Teresa Torres). Hier die Übersicht zu den agilen Praktiken und Canvas aus dieser Episode: Empathy Map Canvas Value Propositiom Canvas Product Vision Board GO Product Roadmap Opportunity Solution Tree

Martin Sallge im Gespräch mit Tim In dieser Folge haben wir Martin Sallge zu Gast. Er ist der Director Customer Journey bei DHL und kann uns somit hervorragend aus der Praxis berichten. Wir beleuchten das Verständnis von Customer Journey Management in seinem Kontext. Eine der vielen Fragen: wer ist Kunde, wer ist Nutzer - wie wird das in der Konzernpraxis unterschieden? Einen wichtigen Teil nimmt auch die Frage der Abgrenzung vom Verantwortungsbereich des Customer Journey Teams in einem solchen Großkonzern mit weltweiten Organisationseinheiten ein. Logischer Weise nimmt hierbei die Arbeit mit Stakeholdern auch eine sehr wichtige Rolle ein. Wie sieht nun die Arbeit mit Customer Journeys konkret in der Praxis aus? Um ein geteiltes Verständnis hierbei zu unterstützen hat Martin Sallge zusammen mit seinem Team einen sogenannten Customer Journey Canvas erstellt. Martin erläutert im Gespräch die Nutzung dieses speziellen Canvas - insbesondere bei der Arbeit mit Stakeholdern hilft ihm der Canvas sehr. Auf unserer Webseite stellen wir euch den Customer Journey Canvas zum Download zur Verfügung: https://produktwerker.de/customer-journey-management-im-konzern/ Wenn ihr direkten Kontakt zu Martin aufnehmen möchtet, um weitere Fragen zu stellen, erreicht ihr ihn z.B. bei LinkedIn: https://www.linkedin.com/in/martinsallge/ Wenn euch die Folge gefällt, freuen wir uns über eine positive Bewertung in eurer Podcast App oder als Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Instagram oder Twitter.

Oliver & Dominique im Gespräch Wie wahrscheinlich ist es, dass ihr diese Folge anderen Product Ownern weiterempfehlen würdet? Diese Art der Frage kennen wahrscheinlich sehr viele von uns. Der Net Promotor Score (kurz NPS), ist eine sehr weit verbreitete Form, wenn es um die Erhebung von Kundenfeedback geht. Dabei hat er neben seinen Vorzügen auch ein paar Schwierigkeiten. Grund genug, dass sich Oliver und Dominique intensiver dazu austauschen und ihre Erfahrungen teilen. Die beiden beginnen mit einer Einführung, damit wir eine gemeinsame Ausgangsbasis haben. Wie wird der NPS eigentlich berechnet und wie ist seine Geschichte? Sobald der NPS erhoben ist, stellt sich schnell die Frage, wann der Net Promotor Score des eigenen Produkts eigentlich gut ist. Keine einfach zu beantwortende Frage, der wir uns aber versuchen anzunähern. Ausgehend von der Einordnung, wann ein NPS-Wert gut oder schlecht ist besprechen wir verschiedene Hinweise, die beim Einsatz des Net Promoter Scores berücksichtigt werden sollten. Ein paar weitere Quellen zum NPS möchten wir euch gerne mitgeben: The One Number You Need to Grow von Frederick F. Reichheld What is a Good Net Promoter Score? Würden Sie diese Methode einem Freund empfehlen? von Stefan Ruf Warum der Net Promoter Score schädlich ist Im Zusammenhang mit dieser Episode solltet ihr auch diese Podcast-Folgen anhören: Erfolgreiche Nutzerinterviews führen Impulse für ganzheitliche Kundenzentrierung Wenn euch die Folge gefällt, freuen wir uns über eine positive Bewertung in eurer Podcast App oder als Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Instagram oder Twitter.

Indra Burkart im Gespräch mit Dominique Customer Journey Maps beschreiben die Geschichte der Interaktion von Kundinnen und Kunden mit unserem Produkt. Dabei visualisieren diese Maps an welchen Stellen welche Interaktion auftritt und wie Menschen damit umgehen. Obwohl diese Technik eher aus dem Bereich Customer Experience Design oder User Experience Design kommt, sehen wir hier ein spannendes Potential für die Arbeit von Product Ownern. In dieser Folge sprechen wir deshalb mit Indra Burkart, die im Rahmen ihres Arbeitsalltags immer wieder auf diese Technik zurückgreift. Dabei klären wir nicht nur, was Customer Journey Maps sind, sondern auch wie wir sie entwickeln und wer daran beteiligt ist beziehungsweise sein sollte. Wir streifen den Moment der Wahrheit, den man in den Maps wiederfinden kann und besprechen auch, welche Probleme beim Entwickeln der Maps auftreten können. Wie immer schließt unser Gast mit wertvollen Tipps und Tricks ab, die euch beim Einsatz der Technik helfen sollen. Neben ihrer Arbeit berichtet Indra übrigens auf ihrem Youtube-Kanal über viele verschiedene Aspekte von User Experience. Sie befasst sich dort sowohl mit Basiswissen als auch mit Methoden und verschiedenen Alltagherausforderungen. Ihren Kanal können wir sehr empfehlen. Mehr über Indra findet ihr aber auch auf LinkedIn. Wenn euch die Folge gefällt, freuen wir uns über eine positive Bewertung in eurer Podcast App oder als Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Instagram oder Twitter.

Dominique & Tim im Gespräch Was mache ich als Product Owner ohne Scrum Master Unterstützung? Also, falls meine Organisation denkt, dass man sich einen Scrum Master sparen kann oder die/der mehrere Teams gleichzeitig betreut. Sollte ich als Product Owner diese Lücke ausfüllen - denn mein Ziel ist ja der maximale Erfolg meines Produktes. Dominique und Tim diskutieren zunächst die Gründe, warum es in Teams keinen Scrum Master geben könnte. Und stellen fest, dass es diese dysfunktionale Situation wesentlich häufiger gibt als man denkt. Dann gehen sie den Problemen nach, die durch das Fehlen eines Scrum Masters entstehen können. Welche Optionen haben wir als Product Owner in dieser Situation? Sollten die Verantwortlichkeiten des Scrum Master im Team aufgeteilt werden? Laut aktuellem Scrum Guide ist das unserer Meinung nach prinzipiell möglich. Wir raten allerdings dringend davon ab, sowohl Product Owner als auch Scrum Master Verantwortlichkeiten gleichzeitig zu übernehmen. Das Team besser zu machen, durch Inspect & Adapt der Zusammenarbeit ist nicht euer Job. Trotzdem versuchen Tim & Dominique in dieser Folge euch Tipps zu geben, wie ihr mit dieser Situation besser umgehen könnt. In dieser Episode genannte Quellen: Zombie Scrum Survival Guide - Verwijs, Schartau, Overeem Episoden mit Kontext Scrum Master Im Zusammenhang mit dieser Episode solltet ihr auch diese Podcast-Folgen anhören: Mein Freund der Scrum Master Was bedeutet der neue Scrum Guide für Product Owner

Adrian Salamon im Gespräch mit Tim In dieser Folge haben wir Adrian Salamon von tarent solutions zu Gast. Adrian ist Scrum Master und stellt uns das von ihm mit seinem Team entwickelte Vorgehen des sogenannten "Feature Breakdown" vor. Ihr wollt gegenüber euren Stakeholdern aussagefähig sein, wann ein Feature kommt? Ihr wollt alles splitten? Zugleich wollt ihr nicht in irrsinnig langen Refinement Sessions sitzen? Dann hört euch diesen spannenden Erfahrungsbericht des Teams von tarent solutions an. Ausgangslage: Der Product Owner (vom Auftraggeber) und das externe Team waren mit ihrem Refinement Prozess nicht sonderlich zufrieden. Die User Stories waren schlecht geschnitten und hin und wieder fehlte auch mal eine Story, um den vollen Nutzerwert liefern zu können. Die Refinement Meetings waren tendenziell zu lang und zu detailliert. Zugleich baten die Stakeholder schon oft sehr früh um zumindest grobe Schätzungen (Zeit/Geld) für einzelne Features. Keiner war so richtig zufrieden mit der Situation. Dies war der Startpunkt einer Lernreise mit verschiedenen Experimenten, über die Adrian im Gespräch ausführlich berichtet und seine Learnings teilt. Dabei ist das Team an Behavioral Driven Development, Three-Amigos-Meetings und mehrstufigen QA-Checks vorbeigekommen. Aber immer blieb eine Unzufriedenheit: entweder mit der Geschwindigkeit der Meetings und/oder mit der Qualität und Sinnhaftigkeit der User Stories. Nach einigen Iterationen fand Adrian zusammen mit seinen Teammitgliedern von tarent sowie den Stakeholdern auf Kundenseite ein Vorgehen ("Feature Breakdown"), welches allen Beteiligten sehr hilft, (zu) große Features in effektiver Weise runter zu brechen. Dabei wird durch Adrian als Scrum Master auf ein sehr striktes Timeboxing geachtet, was zu großer Effizienz führt. Das vorgestellte Verfahren wird in dem international verteilten Team von tarent natürlich komplett remote durchgeführt. Adrian Salamon hat das ganze Vorgehen auch in einem Blogpost seiner Firma ausführlich beschrieben: https://www.tarent.de/blog/improving-the-flow Im Kontext dieser Folge könnten auf diese Episoden für euch relevant sein: Hilfe, mein Backlog ist explodiert Mein Freund der Scrum Master Wenn ihr direkten Kontakt zu Adrian aufnehmen möchtet, um weitere Fragen zu stellen, erreicht ihr ihn z.B. per Mail: a.salamon@tarent.de Wenn euch die Folge gefällt, freuen wir uns über eine positive Bewertung in eurer Podcast App oder als Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Instagram oder Twitter.

Tim & Dominique im Gespräch Wie groß sollte eigentlich ein Product Backlog sein? Auch wenn es auf diese Frage keine konkret quantifizierbare Antwort gibt, widmen wir uns diesmal dem Problem, dass das Backlog "zu groß" ist. Dominique und Tim diskutieren zunächst, was für sie selbst "zu groß" wäre. Dann gehen sie den Gründen nach, warum ein Product Backlog explodiert sein könnte. Natürlich kann ein simpler Grund auch sein, dass man als Product Owner ein bestehendes Product Backlog übernimmt, was bereits überquellt. Und wie bekomme ich das Problem wieder in den Griff? Welche Tipps und Praktiken gibt es also, um das Backlog wieder zu verkleinern? Zudem diskutieren Tim und Dominique, mit welchen Strategien ich vorsorgen kann, damit das Product Backlog nicht zu voll wird bzw. nicht zumüllt. In dieser Episode genannte Quellen: Roman Pichler: Be a Balanced Product Leader, not a Feature Broker or Product Dictator Im Zusammenhang mit Product Backlog Management solltet ihr auch diese Podcast Folgen anhören: Das Product Backlog Features wegwerfen - was braucht es dafür außer Mut? Product Backlog Einträge sind nicht nur User Stories! Story Mapping nutzen, um über Outcome zu sprechen Wenn euch die Folge gefällt, freuen wir uns über eine positive Bewertung in eurer Podcast App oder als Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Instagram oder Twitter.

Christiane Mehling im Gespräch mit Oliver Gast der heutigen Episode ist eine Expertin zum Thema Product Leadership - Christiane Mehling, Head of Product & Design VoD bei der Mediengruppe RTL. Gemeinsam mit ihrem Team ist sie in der Produktverantwortung für das Streaming-Angebot TVNOW. Oliver fragt Christiane nach den Herausforderungen und ihren persönlichen Erfahrungen, die erste Product Ownerin in einem großen Unternehmen gewesen zu sein, welches ein erstes Scrum Team quasi als Experiment gestartet hatte. Was hat funktioniert? Wie ist es gelungen, tatsächlich mehr und mehr Ownership für das Produkt zu übernehmen und auf welche Fragen stieß Christiane, als das Unternehmen von einem auf sechs Teams skalierte. Loslassen und Vertrauen Nachdem sie nun für mehrere Product Ownerinnen verantwortlich war, konzentrierte sie sich mehr auf die strategischen Aufgaben. Und lernte in operativen Fragen loszulassen und ihrem Produktteam zu vertrauen. Inspiriert von David Marquets Buch "Turn the ship around" entwickelten sie eine gemeinsame Vorstellung, wie ein Zusammenspiel in ihrem individuellen Kontext funktionieren könnte. Kommende Herausforderung Als den nächsten, logischen Schritt hin zu Product Leadership zieht Christiane eine Coachingausbildung in Betracht. Weniger Expert Leader, noch mehr Catalyst Leader ist ihr Ziel. So begeistert, wie sie darüber erzählt, glauben wir, dass ihr auch dieser Schritt gelingen wird. Im Lauf der Episode gibt Christiane zahlreiche Tipps & Tricks aus ihrer eigenen Erfahrung für den Weg hin zu einer Product Leaderin. Wer einen detaillierteren Eindruck von Christiane bekommen möchte, dem sei dieses Video empfohlen. Sie sucht aktuell noch Menschen, die ihr Produktteam verstärken möchten.

Oliver & Dominique im Gespräch Das Sprint Planning ist für Product Owner ein wichtiges Event in Scrum. Dennoch passieren oft zahlreiche Fehler im Hinblick auf Selbstorganisation und Product Ownership des ganzen Teams. Zudem fühlt das Planning sich für viele Product Owner auch häufig eher merkwürdig an. Oliver und Dominique berichten von ihren eigenen Erfahrungen und welche Fehler ihnen selbst im Sprint Planning schon unterlaufen sind. Im Gespräch beleuchten die beiden das Event aus Sicht des Product Owners. Dabei geht es sowohl um die Zweck, den das Planning für den Product Owner erfüllen soll, welche Vorbereitungen man treffen sollte und letztlich wie ich ein gutes Sprint Planning als Product Owner gestalte. Die Ergebnisse aus dem Sprint Planning haben einen großen Einfluss auf den Erfolg eines Sprints. Daher ist es so wichtig, die drei grundsätzlichen Fragestellungen gut zu bearbeiten: Warum, Was und Wie? Warum? Als Product Owner solltest Du einen Vorschlag machen, warum es Sinn macht, in den nächsten Sprint zu investieren und damit dem Team auch die Relevanz erklären können. Den Kontext für das kommende Sprintziel geben dabei Produktvision, Roadmap und Product Goal. Was? In diesem Schritt erfolgt die Auswahl der Product Backlog Elemente und ihre Übernahme in das Sprint Backlog durch bzw. gemeinsam mit den Developern. Dabei sollte der Fokus darauf liegen, was zur Erfüllung des Sprintziels notwendig ist und nicht ob die Auslastung aller Teammitglieder sichergestellt ist. Schließlich wollen wir primär den Wert des Produkts maximieren und nicht die Auslastung optimieren. Wie? Während die Developer in diesem Schritt planen, wie sie während der Iteration vorgehen wollen, um das Sprint Goal zu erreichen, nimmt der Product Owner eine passive Rolle ein und steht mindestens für weitere Rückfragen und Entscheidungen zur Verfügung. Stolperfalle: hier geht es ums Planen, wie das Team das "Wie" angeht - noch nicht um die (technische) Konzeption und Lösungsfindung an sich! Als Ergebnis vom Sprint Planning haben wir ein vollständiges Sprint Backlog. Dies umfasst das Sprintziel, die ausgewählten Items und den gemeinsam erstellten Plan für Umsetzung.

Katja Busch im Gespräch mit Dominique Manchmal ist man als PO der Meinung, dass die User Experience des eigenen Produkts wichtig ist. Die eigenen Stakeholder sehen das aber nicht immer auch so. Darum sprach Dominique in dieser Folge mit Katja Busch über das Vermitteln der Relevanz von UX an die Stakeholder. Sie behandeln in dieser Folge zum Beispiel den Nutzen von Empathie als "Superkraft" bei der Zusammenarbeit mit anderen Menschen, die Bedürfnisse von Stakeholdern und wann UX in Konkurrenz zu anderen Anforderungen steht. Und wie immer schließen wir natürlich auch mit ein paar Tipps, wie ihr die Wichtigkeit von UX leichter vermitteln könnt. Katjas Gedanken und Erfahrungen finden sich auch im umfangreichen Aufbau-Training für UX-Management wieder, dass wir hier guten Gewissens empfehlen können. (eLearning mit Live-Workshops, https://www.haufe-akademie.de/30800). Wer noch mehr von ihr erfahren will findet sie sowohl auf Xing (https://www.xing.com/profile/Katja_Busch), LinkedIn (https://www.linkedin.com/in/katja-busch-525b9820) und Twitter (https://twitter.com/mataair).