Die Produktwerker

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).

Tim & Oliver im Gespräch Für das Thema der aktuellen Folge unseres Podcast "Agile Product Roadmaps" wurde es langsam mal Zeit. Tim und Oliver tauchen daher in die Produktstrategie ein. Sie besprechen, dass Product Roadmaps Antworten auf die folgende Fragen geben sollte: Welche großen Schritte nimmt unsere Produktentwicklung, welche Ziele verfolgen wir, und was ist der Outcome & der Output? Und fast nebenbei überlegen beide, was dies mit Schatzkarten zu tun haben könnte. Roadmaps sind oft Feature based und listen die geplanten und zu erwartenden Features in zukünftigen Zeitintervallen auf. Outcome orientierte Roadmaps definieren primär das Ziel und zugehörige Metriken, die wir als Product Owner:in erreichen wollen. Tim und Oliver diskutieren in diesem Zusammenhang die Frage, welcher Roadmap Typ in welchem Kontext am sinnvollsten eingesetzt werden sollte. Ein weiterer Themenschwerpunkt der Podcastfolge sind die Erwartungshaltungen von Stakeholdern an Roadmaps. Als Product Owner:in sollte ich diese Anforderungen und Erwartungen kennen und auf deren Basis über die Elemente sowie Gestaltung der Roadmap nachdenken. Dies schafft Transparenz, Orientierung, Fokus und Motivation für alle an der Produktentwicklung beteiligten Personen, einschließlich des eigenen Scrum Teams. So wird eine Roadmap nicht zu einem konkreten Plan mit garantierten Lieferterminen degradiert, sondern sorgt für Alignment in der eigenen Organisation. Als Product Owner:in sorge ich dafür, den Erstellungs- und Reflexionsprozess bestmöglich zu faszilitieren. Im Podcast erwähnte Quellen: Öffentliche Roadmap von Buffer Buch-Empfehlung: Product Roadmaps Relaunched Strategize - Product Strategy & Product Roadmap Blog-Post von Roman Pichler: Product Goals in Scrum

Florian Meyer im Gespräch mit Tim Was für eine großartige Episode! Florian Meyer gelingt es, dieses wirklich komplizierte Thema sehr greifbar zu erklären. Wir konzentrieren uns für den Einstieg v.a. auf das Artefakt der "Wardley Map" und streifen den ganzen Strategiezyklus des "Wardley Mappings" bewusst nur oberflächlich. Unser Ziel war es auch nie, euch das komplette Wardley Mapping in einer Episode zu erklären, sondern einen guten ersten Impuls zu setzen, damit ihr euch nach diesem Einstieg für das Thema interessiert und einen guten Einstieg ins weitere Material findet. Wir glauben, das ist Florian im Gespräch mit Tim gelungen. Als Einstieg vor den originalen Wardley Videos empfehlen wir Euch den deutschen Vortrag von Markus Andrezak von der LeanDUS14 ansehen. Dort erklärt Markus ab der 32.Minute die Wardley Maps (ab der 50.Minute kommt dann nochmals etwas zu Wardley). Und danach empfehlen wir das Original anzusehen: Simon Wardley: Crossing the river by feeling the stones The Leading Edge Forum Course Cat Swetel: Continuous Mapping Talk Ansonsten haben wir weiter unten noch sie superguten YouTube Playlists mit einer super Übersicht über alle von Florian Meyer empfohlenen Videos aufgeführt. Literatur: Simon Wardley: On being lost John Boyd zu OODA-Loops im Buch The Fighter Pilot Who Changed the Art of War Sun Tsu ("Sunzi"): Die Kunst des Krieges (Wikipedia) YouTube Channels/Playlists: Wardley Mapping (Videos auf Deutsch) Wardley Mapping (Allgemeine Videos) Wardley Maps Channel Ben Mosior Hired Thought (Videos) Tools: Strategie-Phrasen-Generator: "What is my Strategy?" Miro-Vorlage von Ben Mosior und Miro-Artikel Super Tool Übersicht von Ben Mosior: https://learnwardleymapping.com/tools/ Online-Tool von Damon Skelhorn inkl. Visual Studio Extension: https://onlinewardleymaps.com/ Tool von Excalidraw https://excalidraw.com/ Wardley's Doctrine (universally useful patterns that a user can apply regardless of context) https://doctrine.wardleymaps.com

Oliver & Tim im Gespräch Gibt es eine Gefahr vom Product Owner zum Projektmanager zu werden? Vielleicht sogar unbemerkt? Oliver und Tim gehen dieser Frage nach und diskutieren zunächst, woran man dies merken könnte. Dabei kann die eine Dimension die Art meiner Tätigkeiten sein. Weiterhin gilt es das Team bzw. das allgemeine Verhalten in den Scrum Events zu beobachten. Und als dritten Einflussbereich besprechen die beiden das Verhalten der Stakeholder. Insgesamt ist bei der Frage wohl der organisatorische Kontext entscheidend. Welche Erwartungshaltungen werden von außen an die Product Owner Rolle gestellt und welche Einflüsse hat das Umfeld des Produktes? Stand im Produktlebenszyklus und der sogenannte Horizont (gemäß 3-Horizonte-Modell) in dem das Produkt (weiter)entwickelt wird, spielen letztlich eine große Rolle. Was kannst du selber in einer solchen Situation tun, wenn du merkst, immer mehr als Projektleiter*in zu agieren? Tim und Oliver geben in ihrem Gespräch Tipps und Anregungen, welche Strategien und Gewohnheiten helfen könnten sowie welches Verhalten ihr vermeiden solltet. Im Gespräch gibt es u.a. einen Verweis auf die folgende Podcast-Episode wenn es darum geht den Kontext Deines Produkts zu ermitteln: Welche Aufgaben gehören zur Product Owner Rolle. Hierbei kann Dir unser Product Ownership Context Canvas (POCC) helfen. Im Zusammenhang mit der Verantwortung des Product Leaders für die Positionierung als Product Owner bzw. Projektmanager haben wir auch nochmal den Hinweis auf die sehr gute Podcast-Folge mit Petra Wille zu ihrem u.g. Buch gegeben: Starke Produktmanager entwickeln Im Verlauf des Gesprächs gibt Oliver auch noch die folgenden beiden Literatur-Tipps: Marty Cagan: EMPOWERED: Ordinary People, Extraordinary Products Petra Wille: STRONG Product People - A Complete Guide to Developing Great Product Managers 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 bzw. via Instagram oder Twitter.

Daniel Ley im Gespräch mit Dominique In dieser Folge unterhält sich Dominique mit Daniel Ley, einem erfahrenen UX Strategy Manager darüber, wie wir erfolgreich Nutzerinterviews führen können. Wir bauen unsere Produkte schließlich nicht für uns sondern für andere Menschen. Darum liegt es nahe sich auch mit Menschen aus dem Kreis der erwarteten Nutzer und Nutzerinnen zu unterhalten, um herauszufinden was sie bewegt und welche wichtigen Aspekte wir bei der Produktgestaltung berücksichtigen sollten. Daniel arbeitet als UX Strategy Manager im Innovationsteam von Amadeus. Dort validiert er gemeinsam mit Kollegen aus aller Welt neue Geschäftsideen nach dem Lean Startup Prinzip. Er organisiert darüber hinaus das UX Bonn Meetup (http://uxbn.de/) mit und begeistert sich für alle Themen rund um mechanische Armbanduhren, Möbeldesign und Architektur. Mehr zu Daniel findet ihr unter https://www.linkedin.com/in/daniel-ley-171729a1/ Im Gespräch verweist Daniel auf folgende Inhalte: Tomer Sharon - How to ask questions Talking to Humans Transkription Service Trint Darüber hinaus hat Daniel noch ein paar weitere Tipps für uns: Get better data from user studies: 16 interviewing tips How to do a user interview (from Google Ventures updated) What people are really doing Validating Product Ideas 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 Warum sollten wir auch mal Features wegwerfen? Dieser Frage gehen Dominique in dieser Folge nach. Nachdem mögliche Gründe geklärt sind, diskutieren sie die Frage, welche Anzeichen es gibt, Funktionen auszubauen. Wann und woran merke ich, dass ich etwas wegwerfen sollte? Aber selbst wenn wir es merken, tun wir das dann oft doch nicht. Was hindert uns denn am Wegwerfen? Und wenn wir uns mal trauen, stellt sich die Frage: Welche Features wegwerfen? Wie treffe ich hierfür die richtige Entscheidung? Dabei diskutieren wir u.a. auch, ob wir die Nutzer und Kunden informieren sollten und mit welcher Strategie man vorgehen könnte, um Funktionen zu eliminieren. Im Gespräch gibt es u.a. einen Verweis auf die folgende Podcast-Episode wenn es darum geht zu diskutieren und zu entscheiden, welche Features weggeworfen werden könnten: Nutze Story Mapping, um mit Stakeholdern ü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.

Dominique im Gespräch mit Jens Scharnetzki In dieser Folge sprach Dominique mit Jens Scharnetzki, seines Zeichens Chief Product Owner bei der Yello Strom GmbH. Die beiden sprechen über den Werdegang eines Designers hin zum Chief Product Owner. Jens erzählt von seiner Ausbildung im Designbereich und den anschließenden Stationen bis hin zum Chief Product Owner. Er beschreibt, was ihn an der Rolle reizt und welche Vorteile es für ihn hat, einen Hintergrund als Designer zu haben. Er erzählt, welche Eigenschaften und Verhaltensweisen ein guter Chief Product Owner vereinen sollte und offenbart auch, was ihm an der Rolle keinen Spaß macht. Natürlich kommen wir nicht darum, mit ein paar Tipps für Product Owner und Product Leader zu schließen. Mehr zu Jens findet ihr unter https://www.linkedin.com/in/scharnetzki.

Oliver & Dominique im Gespräch Mit Forecasting sollte sich unserer Meinung nach jede Product Owner:in intensiv beschäftigen. Ein Forecast ist eine Prognose über einen Liefertermin und Features, verbunden mit der Wahrscheinlichkeit, dass unsere Prognose richtig ist. In vielen Produktentwicklungs-Kontexten gibt es Dritte, die auf diese Prognosen angewiesen sind, um selber ihre Aufgaben termingerecht erledigen zu können. Diese Kollegen sind also von unseren Arbeitsergebnissen abhängig. Also braucht es ein Forecasting der Product Owner:in, damit wir die Tätigkeiten syncronisieren. In der heutigen Forge sprechen Dominique & Oliver über ihr Vorgehen beim Erstellen eines Forecast. Sie diskutieren verschiedene Ebenen, auf denen mit einem Forecast gearbeitet wird. Und sie stellen Unterschiede in ihrem persönlichen Vorgehen fest. Ein Schwerpunkt der Folge liegt dann auf dem Thema Forecasting für die Releaseplanung - sicher eine Herausforderung für jede Product Owner:in. Oliver & Dominique geben darüber hinaus viele praktische Tipps aus ihrer eigenen Praxis als Produkt Owner, z.B. Umgang mit Unsicherheit und hohen Risiken, der Einsatz von Story Points und regelmäßiges updaten von Forecasts sowie die Rolle der Prognosen in der Stakeholder Kommunikation. Quelle: Mike Cohn: Agile Estimating and Planning

Markus Andrezak & Sohrab Salimi im Gespräch mit Dominique und Tim Wir haben Markus Andrezak und Sohrab Salimi zum gemeinsamen Gespräch mit Dominique und Tim eingeladen. Während Sohrab und Tim eher aus der Businessecke kommen, haben Markus und Dominique ihr Standbein in der Nutzer-Domäne. Aus dieser feinen Mischung entstand ein intensives Gespräch darüber, worauf Product Owner (mehr) achten sollten bzw. wie man beide Welten auch gut verbinden kann. Unser Flow war so gut, dass diese Episode ausnahmsweise mal etwas länger ist. Wir sind überzeugt, dass sich die Zeit lohnt, mit zwei solch ausgewiesenen Produktmanagement Experten und Trainern mal tiefer einzusteigen. So ging es auch intensiver in die Themen Change und Business Agility. Am Ende geben Markus und Sohrab ihre wertvollen Tipps, was man lernen, lesen und hören sollte, um gut in die Product Owner Rolle hineinzuwachsen oder in ihr besser zu werden. Ein toller Satz der hängen bleibt: "Agile Produktentwicklung gibt Dir Sicherheit im Vorgehen, um die Unsicherheit in den Anforderungen ertragen zu können". Diese Folge ist voll von solch starken Analogien und lebhaften Beispielen. Markus und Sohrab waren auch schon zu Beginn unseres Podcasts zu Gast. Ihre immer noch sehr lohnenswerten und oft gehörten Folgen legen wir euch daher zudem ans Herz: Markus Andrezak in Folge 3: "Warum scheint die Product Owner Rolle so schwer zu sein?" Sohrab Salimi in Folge 11: "Product Owner als Agile Leader" Im Gespräch nennen Sohrab und Markus eine Menge Quellen: Eric Ries: Lean Startup Alex Osterwalder & seine Arbeiten auf Strategyzer Fallstudie MAN über "Agilität in der Automobilentwicklung" HBR-Artikel "Embracing Agile" Roger L. Martin: Playing to Win - How Strategy Really Works Erika Hall: Just Enough Research Claudia Kotchka bzgl. Design Thinking bei Procter & Gamble Buch über Pixar von Ed Catmull: "Die Kreativitäts-AG - Wie man die unsichtbaren Kräfte überwindet, die echter Inspiration im Wege stehen" Podcast mit Yvon Chouinar‪d‬ über die Geschichte von Patagonia Buch von Reed Hastings: Keine Regeln - Warum Netflix so erfolgreich ist Buch Clayton M. Christensen: The Innovator's Solution - Warum manche Unternehmen erfolgreicher wachsen als andere Buch Clayton M. Christensen: The Innovators Dilemma - Warum etablierte Unternehmen den Wettbewerb um bahnbrechende Innovationen verlieren Podcast How I build this von Guy Raz Wir freuen uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Instagram, LinkedIn bzw. auf Twitter @produktwerker.

Dominique & Tim im Gespräch User Stories werden von vielen Product Ownern ihren Product Backlogs als eine Form von Product Backlog Items genutzt. Aus der Perspektive von Nutzern beschreiben wir so den Mehrwert, den wir mit unseren Produkten ermöglichen wollen. Allerdings gibt es einige Herausforderungen beim Verwenden dieses Formats. Darum unterhalten sich Dominique und Tim in dieser Folge über User Stories als Möglichkeit Anforderungen zu formulieren und klären welche Vorzüge dieses Vorgehen hat und welche Herausforderungen gemeistert werden müssen. Diese Folge verweist u. A. auf folgende Folgen des Podcasts: Akzeptanzkriterien richtig einsetzen Product Backlog Einträge sind nicht nur User Stories! Story Mapping nutzen, um über Outcome zu sprechen Literatur/Quellen: Mike Cohn: User Stories - für die agile Software-Entwicklung mit Scrum, XP u.a. Gojko Adzic: Fifty Quick Ideas to Improve Your User Stories Gojko Adzic: Specification by Example - How Successful Teams Deliver the Right Software Jeff Patton: User Story Mapping - Nutzerbedürfnisse besser verstehen als Schlüssel für erfolgreiche Produkte Dominique: Persona-driven User Stories

Hendrik Neumann im Gespräch mit Dominique In dieser Folge sprach Dominique mit Hendrik Neumann über seinen Werdegang und seine Erfahrungen aus der Verantwortung als Teamleiter Produktmanagement bei Chefkoch. Hendrik erzählt uns, warum ihn die Verantwortung als Product Owner gereizt hat und wie er schließlich Teamleiter wurde. Er führt uns durch die Herausforderungen, die diese Rolle mit sich brachten und wie er seine Aufgabe als Führungskraft ausgelebt hat. Natürlich schließt er mit ein paar Tipps, die er anderen mitgeben möchte, die sich in eine ähnliche Richtung entwickeln. Mehr zu Hendrik findet ihr unter https://www.xing.com/profile/Hendrik_Neumann18/cv.

Tim & Oliver im Gespräch "Story Mapping ist meine liebste agile Praktik" sagt Tim. Im Gespräch mit Oliver erläutert er daher seine Leidenschaft für die Methode des Story Mapping und wie & wo er Story Maps gerne einsetzt. Natürlich erfahrt ihr auch, aus welchen grundlegenden Elementen Story Maps bestehen und wie ihr sie mit euren Teams und Stakeholdern entwickeln könnt. Tim erklärt, warum für ihn die Diskussion über Wirkungsschnitte ("Target Outcomes") so zentral ist, aber dennoch oft vernachlässigt wird, wenn es um Story Mapping geht. Zudem helfen solche Wirkungsschnitte massiv in der Diskussion mit deinen Stakeholdern. Zum anderen sorgt es für Klarheit - auch in der Diskussion mit dem ganzen Scrum Team bzw. Produkt- oder Projektteam. Target Outcomes bilden für Tim eine perfekte Verbindung zwischen einer agilen Roadmap und der Story Map. Je nach Abstraktionsebene kann ein solches Target Outcome sogar als Product Goal dienen. Wobei Product Goals vermutlich in der Regel etwas größer als ein Target Outcome sein dürften. Wenn ihr in dieser Weise ein (oder zwei) einzelne Slices der Story Map in euer Product Backlog überführt, habt ihr sofort mehr Fokus und damit Klarheit im Backlog. Auch Sprintziele (Sprint Goals) werden sich so sicherlich einfacher finden lassen. Zum Product Goal und Sprint Goal haben wir bereits Episoden in diesem Podcast veröffentlicht. Tim erwähnt diese Story Mapping Quellen Jeff Patton: User Story Mapping (Buch) Jeff Patton: Story Mapping (Quick Reference) Jeff Patton: Opportunity Canvas (Template) Handouts, Übungen & Trainingsmaterial und der direkte Zugriff in die Dropbox von Jeff Patton

Petra Wille im Gespräch mit Dominique und Tim Wir besprechen mit Petra Wille ihr neues Buch "STRONG Product People: A Complete Guide to Developing Great Product Managers". Petra Wille ist unabhängiger Product Leadership Coach und Autorin, die seit 2013 Produktteams dabei hilft, ihre Fähigkeiten zu steigern und sich zu verbessern. Neben ihrer freiberuflichen Tätigkeit ist Petra Mitorganisatorin und Kuratorin von "Mind the Product Engage" Hamburg, Deutschland. Mehr über die Arbeit von Petra: https://www.strongproductpeople.com/ Petra teilt ihr Erkenntnisse aus ihrer Tätigkeit und Erfahrung als Product Leadership Coach. Was macht einen guten Produktmanager aus, wie entwickle ich mich weiter, welche Aufgabe fällt dabei der Führungskraft zu. Eine Folge also, die Euch zahlreiche Impulse für die persönliche Weiterentwicklung geben kann. Folgende Bücher und Quellen werden in der Folge erwähnt: Richard Banfield, Martin Eriksson, Nate Walkingshaw: Product Leadership: How Top Product Managers Create and Launch Roman Pichler: How to Lead in Product Management Marty Cagan: Empowered - Ordinary People, Extraordinary Products Kate Leto: Hiring Product Managers: Using Product EQ to go beyond culture and skills Talks: Shaun Russell: How Successful Product People Develop Bzgl. der u.a. von Petra Wille organisierten Konferenz "MTP Engage" verweisen wir auf unsere ganz frühe Podcast-Folge "Wann lohnen sich Konferenzen und Barcamps für Product Owner?"

Kerstin Neumann im Gespräch mit Tim Kerstin Neumann gibt einen spannenden Einblick und Erfahrungsbericht in ihr Verständnis von Kundenzentrierung. Sie berichtet, wie sie selbst in ihrem Umfeld Impulse gibt und damit das Thema "Product" und "Sicht des Nutzers" nach vorne treibt. Lesetipps von Kerstin zum Thema Kundenzentrierung: Annie Dunham: 12 Things Every Product Manager Should Do in Their First 30 Days at a New Company Andreas Diehl: Customer Centricity – Zehn Methoden für eine höhere Kundenzentrierung Petra Wille: Gefährliche Annahmen – wie ihr das Risiko minimiert, falsch zu liegen Whitepaper: CX-MANAGEMENT ERFOLGREICH UMSETZEN. Praxistipps zur Überwindung von Silogrenzen und zur nachhaltigen Implementierung Matt Watkinson: The Ten Principles Behind Great Customer Experiences Im Gespräch verweist Kerstin zudem auf unsere Podcast-Folge zum Storytelling: Mit Storytelling andere von deinen Produktideen überzeugen Falls ihr direkt mit Kerstin in Kontakt kommen oder ihr folgen wollt: LinkedIn XING 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 Twitter an @produktwerker.

Dominique, Tim & Oliver im Gespräch Die Formulierung von einem Sprint-Ziel als Produkt Owner ist nicht einfach. Dominique, Tim und Oliver klären daher zu Beginn dieser Folge, was sie unter einem Sprint-Ziel überhaupt verstehen. Der neue Scrum Guide von 2020 wertet das Sprint-Ziel als Commitment auf das Sprint-Backlogs auf. Grund dafür ist u.a. die Wichtigkeit, als Scrum-Team Fokus hin auf ein gemeinsames Ziel zu schaffen. Wir geben Euch zahlreiche Beispiele aus der Praxis für die Formulierung von einem Sprint-Ziel als Produkt Owner, den Einsatz im Sprint und Überprüfung der Zielerreichung. Und wir hoffen, dass unsere Tipps & Tricks Euch für die tägliche Arbeit weiterhelfen. Genannte Quellenin dieser Folge: Die Produkt-Speisekarte (Product Menu) – Eine neue Art das Product Backlog zu strukturieren The Sprint Goal Template von Roman Pichler John Cutler: Beyond “Outcomes Over Outputs" und sein zentraler Tweet auf Twitter dazu In der Folge verweisen wir u.a. auf unsere Episode zum Product Goal: Das Product Goal und seine Bedeutung für Product Owner