Die Produktwerker

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.