Die Produktwerker

Eike Gehler im Gespräch mit Tim LeSS zwingt den Product Owner, seinen Fokus auf die Priorisierung zu legen und die Klärung von Details zu delegieren! Noch klarer bringt es unser Gast Eike Gehler auf den Punkt: "Prioritization over clarification". Eike ist erfahrener Agile Coach und langjähriger Scrum Master - v.a. bringt er aber sehr viel Erfahrung in sehr großen und skalierten Kontexten mit ins Gespräch ein. Er mag keine Blaupausen und mag am Liebsten zusammen mit den Organisationen die er begleitet herausfinden, welcher Skalierungsansatz im jeweiligen Kontext der geeignete ist. Dabei bedient er sich aufgrund seiner Erfahrung gerne im "Baukasten" verschiedener Skalierungs-Frameworks und -Modelle. Dennoch hat er einen Favoriten: das Framework LeSS - kurz für "Large-Scale Scrum". Dennoch betont Eike Gehler, dass die entscheidende Frage der Produkt-Kontext sei, in dem das Skalierungsvorhaben stattfindet. Tim beleuchtet zusammen mit Eike zunächst dessen eigene Weg in die Agilität sowie seine aktuellen Wirkungskreise in oft großen Organisationen. Zusammen rätseln die beiden, warum das sogenannte "Spotify"-Modell (oder zumindest die dort genannten organisatorischen Formate) derzeit so viele Nachahmer hat. Warum muss jetzt plötzlich alles Squad, Tribe, Gilde usw. heißen? Warum legen Organisationen soviel Hoffnung in diese Organisationsmuster, obwohl dies von Henrik Kniberg und Anders Ivarsson, die damals bei Spotify die Transformation begleiteten, nie als Skalierungs-Framework gemeint war. Tim stellt die These auf, dass "Spotify" derzeit sogar SAFe den Rang abläuft. Tiefer geht es dann um das LeSS-Framework. Hier wird vieles reduziert: für bis zu sieben Feature-Teams ist dort nur EIN Product Owner und nur EIN Product Backlog (innerhalb einer Area) vorgesehen. Eike erklärt zunächst den Begriff des Feature-Teams und wie schwer es oft ist, für diese Idee in großen, bislang silo-artig organisierten Unternehmen Befürworter zu finden. Aber wenn es nur einen Product Owner in LeSS gibt - wie verhält es sich dann mit den Scrum Mastern? Wie viele Scrum Master sind z.B. in einer Area mit fünf Feature Teams sinnvoll? Im letzten Teil geht es nach dieser Herleitung dann ganz konkret um diese Product Owner Rolle in LeSS und welche Herausforderungen sie mit sich bringt. Eike Gehler gibt in diesem Zuge auch noch wertvolle Tipps für Menschen, die als Product Owner in LeSS arbeiten. Quellen zum sog. "Spotify-Model" und LeSS: Die damalige Beschreibung von Henrik Kniberg und Anders Ivarsson der Skalierung bei Spotify… die dann als das Spotify-Model (miss)verstanden wurde. Spotify Engineering Culture, dieses Video wird üblicherweise als Video über das "Spotify-Model" referenziert Henrik Kniberg: No, I didn’t invent the Spotify model Heutige Sicht von Henrik Kniberg auf Scrum@Scale im Vergleich zum "Spotify-Model" Die offizielle Beschreibung von LeSS mit allen Details, die ihr über das (De)Skalierungs-Framework LeSS wissen müsst Wenn ihr mit Eike Gehler in Kontakt treten wollt, freut er sich über eure Nachricht auf folgenden Kanälen: Mail: eike@aykey.de LinkedIn Web Telefon: 089 208044440 Im Zusammenhang mit dieser Episode ist auch die Folge 41 rund um Skalierung empfehlenswert: Product Owner im skalierten Umfeld mit Björn Schotte Welche Herausforderungen erlebt ihr selbst als Product Owner in LeSS oder Ansätzen die sich an das Spotify-Model anlehnen? Wir freuen uns, wenn du deine eigenen Erfahrungen mit uns in einem Kommentar auf unserer Webseite oder auf unserer Produktwerker LinkedIn-Seite teilst. Wenn euch die Folge gefällt, freuen wir uns über eine positive Bewertung in eurer Podcast App oder als Feedback per Mail an podcast@produktwerker.de oder via Instagram oder Twitter.

Oliver & Tim im Gespräch Das Aufteilen (sog. Splitting) von User Stories erscheint oft als eine der schwierigsten agilen Praktiken für Product Owner. Letztlich ist es aber eine Frage der Übung. In dieser Episode besprechen Tim und Oliver "Übungen", um diesen "Muskel" zu trainieren. Es geht also zum Strategien, wie man gute Schnitte zum Aufteilen von User Stories finden kann. User Stories fühlen sich oft zu groß an, um sie in einem Sprint fertig zu stellen. Es ist aber unser Ziel, in regelmäßigen Abständen sinnvolles Feedback zu erhalten, um im komplexen Umfeld in möglichst kurzen Zyklen zu lernen, was unser Produkt wertvoll macht. Vielen Product Ownern und Teams fällt es jedoch schwer, (zu) große User Stories bzw. Features in gute, kleine Stories aufzuteilen. Wir suchen daher immer nach vertikalen Schnitten, so dass wir nach ihrer Umsetzung ein hilfreiches Feedback auf das neue Produktinkrement erhalten können. Wir besprechen u.a. die folgenden Fragen: Wann sind User Stories "zu groß"? Prinzipien und Kriterien beim Aufteilen von User Stories Strategien und Muster, um gute Schnitte zu finden Stolperfallen beim Schneiden von User Stories Grenzen beim Story Splitting: manchmal geht's halt nicht - was dann? Quellen zum Story Splitting Im Gespräch beziehen wir uns auf die folgenden Quellen: INVEST in Good Stories von Bill Wake 10 powerful strategies for breaking down Product Backlog Items in Scrum (with cheatsheet) von Christiaan Verwijs Twenty Ways to Split Stories von Bill Wake User Story Splitting Flowchart von Richard Lawrence (Deutsche Fassung übersetzt von Kai Simons) S.P.I.D.R. Approach von Mike Cohn Im Zusammenhang mit User Story Splitting sind auch weitere Folgen rund um das Product Backlog Management und vor allem in Bezug auf User Stories und andere Product Backlog Elemente empfehlenswert: Erfolgreich mit User Stories arbeiten Akzeptanzkriterien richtig einsetzen Arten von Product-Backlog-Einträgen: Was gibt's neben User Stories noch? Feature Breakdown: schnell User Stories finden und grob schätzen Wie können wir den Erfolg von User Stories messen? Wie läuft das Aufteilen von Anforderungen bzw. das Schneiden von zu großen User Stories bei Euch ab? Wir freuen uns, wenn du deine eigenen Erfahrungen mit uns in einem Kommentar auf unserer Webseite oder auf unserer Produktwerker LinkedIn-Seite teilst. Wenn euch die Folge gefällt, freuen wir uns über eine positive Bewertung in eurer Podcast App oder als Feedback per Mail an podcast@produktwerker.de oder via Instagram oder Twitter.

Dominique & Oliver im Gespräch Jeder macht Fehler und jeder sammelt Erfahrungen. Wie oft denken wir uns dabei, hätten wir das doch früher gewusst. Als das einem von uns vor kurzem wieder mal passiert ist haben wir uns entschieden unsere bisherigen Erfahrungen zu reflektieren und zu sammeln, was wir gerne zu Beginn gewusst hätten. Daher sprechen Oliver und Dominique in dieser Folge über all die Erkenntnisse und Erfahrungen, die sie gerne vorher gewusst hätten. Sie sprechen über Themen wie dem Schnitt der eigenen Verantwortung, die Gesamtheit aller Aufgaben, den eigenen Wirkungskontext, Nutzen verschiedener Backlogs, den Umgang mit anderen Disziplinen und vielem mehr. Im Gespräch verweisen die beiden auf das Buch "Escaping the Build Trap: How Effective Product Management Creates Real Value" von Melissa Perri. In diesem geht es vor allem darum nicht immer nur neue Features zu bauen, sondern das Produkt als Ganzes weiterzuentwickeln und ggf. auch mal Features zu entfernen, wenn sie keinen Mehrwert liefern. Was die Rolle als Product Owner angeht referenziert Oliver auf das "POEM", ein Instrument zum besseren Verständnis der Product Ownership. Mehr dazu findet ihr hier: https://productownership.de/poem/ Und nun ist es auch an euch eure Erfahrungen zu teilen. Was hättet ihr gerne vorher schon gewusst?

Mick Hohmann im Gespräch mit Oliver Was sollte ich in meiner Verantwortung als Product Owner wirklich niemals tun? Was sind absolute NoGos? Oliver spricht in dieser Folge mit Mick Hohmann über seine persönlichen Erkenntnisse zu diesem Thema. Mick hat 5 NoGos mitgebracht, die er in der Diskussion ausführlich erläutert: Product Owner ist nicht Teil des Teams oder wird nicht so wahrgenommen Product Owner übernimmt Scrum Master Aufgaben Das Fehlen einer Produktvision Fehlendes Wissen über Wert & Kosten Nutzer als Stakeholder wird vergessen Und Mick hat dann als Bonus noch ein weiteres NoGo dabei, welches an dieser Stelle aber noch nicht erraten wird. ;) Solltest du den einen oder andere Punkt auch bei dir erkennen, dann kann sicher der Scrum Master weiterhelfen. Wir empfehlen daher gerne die Episode "Dein Freund der Scrum Master" mit Steffi Götten, weil wir dort einige Lösungsansätze zur Überwindung der NoGos besprochen haben.

Dominique und Oliver im Gespräch Keiner mag Bugs, aber es ist vollkommen normal, dass welche entstehen. Oliver und Dominique sprechen in der Folge darüber, wie wir als Product Owner mit Bugs umgehen können. Dazu müssen wir natürlich erst einmal kurz darüber sprechen, was Bugs eigentlich sind. Danach stürzen die beiden sich auf verschiedene Ansätze. Bugs können im Product Backlog eingeplant werden. Alternativ kann auch ein eigenes Bug-Backlog eingerichtet werden, an dem pro Sprint eine feste Zeit (Timebox) gearbeitet wird. Man könnte auch so arbeiten, dass ein Mitglied des Dev-Teams in einem Sprint nur Bugs abreitet. Diese verschiedenen Ansätze haben aber alle Vor- und Nachteile, weshalb unsere Diskussion in eine klare Richtung geht. Wir sind gespannt zu hören, was eure erprobten Praktiken sind, um Bugs angemessen zu behandeln. Schreibt es uns gerne in die Kommentare unter https://produktwerker.de/wie-product-owner-mit-bugs-umgehen-sollten/

Daniel Hommel im Gespräch mit Oliver In dieser Podcastfolge sprechen wir über Coaching. Oliver hat sich dazu Daniel Hommel von der Agile Unternehmensberatung Emendare eingeladen. Als Certified Professional Co-Active Coach und aktiver Teil des ICF Chapter in Deutschland ist Daniel der richtige Gast, um Coaching mit Fokus auf die Verantwortung eines Product Owners zu diskutieren. Nachdem Daniel und Oliver die Definition von Coaching geklärt haben, schauen sie auf unterschiedliche Themen, bei denen es hilfreich sein kann, als Product Owner gecoacht zu werden. Dass der Coach dabei nicht notwendigerweise immer der Scrum Master sein muss, erschließt sich oft erst auf den zweiten Blick. Als Product Owner sollte ich mir über das Thema, an dem ich im Coaching arbeiten will, bewusst sein und mir dafür die erfolgsversprechenste Unterstützung suchen. In der Regel werden Scrum Master und Product Owner aber eine Doppelspitze bilden. Daniel gibt aus seiner eigenen beruflichen Praxis Tipps, wie ich als Product Owner den Scrum Master um mehr Coaching-Support bitten kann und so beide profitieren.

Dominique und Tim im Gespräch Es kann nur einen Product Owner geben, aber kann dieser nicht auch vielleicht im Team mitarbeiten? Besonders dann, wenn ein Product Owner vorher schon mal als Mitglied des Dev-Teams mitgewirkt hat, ist dieses Verhalten zu sehen. In dieser Folge besprechen Dominique und Tim ihre Erfahrungen mit solchen Szenarien. Sie klären mögliche Gründe, aber auch welche Probleme bei einem solchem Vorgehen auftreten können. Beispielsweise kann ein Product Owner durch zwei Verantwortungen ziemlich überlastet werden und das eigene Denken verfestigt sich manches mal sehr im Lösungs- statt auch mal im Problemraum. Darum diskutieren die beiden auch über mögliche Lösungsansätze bzw. Hilfen, die aus der Situation herausführen und helfen Konflikte zu vermeiden. Mögliche Lösungsansätze aus der Folge sind beispielsweise: Role Model Canvas 2.0 (https://www.visual-braindump.de/role_model_canvas/) Delegation Poker (https://management30.com/practice/delegation-poker/) POEM (Product Ownership Evolution Model; https://productownership.de/poem/) Darüber hinaus möchten wir euch zum Thema noch eine Folge des Podcasts "Mein Scrum ist kaputt" mit Tim zum POEM ans Herz legen: https://meinscrumistkaputt.de/folge-103-poem/ 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.

Isabella Thissen im Gespräch mit Oliver Thema dieser Podcastfolge sind digitale Geschäftsmodelle. Ein Geschäftsmodell beschreibt die Logik, wie eine Organisation Werte schafft, vermittelt und erfasst. Die Grundlage für ein Geschäftsmodell ist meist ein nutzerzentriertes Produkt, allerdings gehen Geschäftsmodelle über die reine Produktsicht hinaus. Isabella Thissen, Senior Vice President Editorial Products & Innovation bei der Mediengruppe RTL, spricht mit Oliver über Business Models. Und wie intensiv sich Product Owner:innen mit diesem Thema auseinandersetzen sollten. Anhand von Beispielen aus ihrem eigenen Umfeld zeigt Isabella, dass es sich durchaus lohnt, auch bei etablierten Produkten immer mal wieder auf das Business Modell zu schauen. Dabei darf natürlich ein Blick auf den wohl bekanntesten Vertreter, das Business Model Canvas von Strategyzer nicht fehlen. Aber auch das Platform Design Toolkit wird von Isabella erklärt und eingeordnet. Links auf die Modelle / Webseiten, die Isabella und Oliver in dieser Folge erwähnen: Books: Business Model Generation & Value Proposition Design (Strategyzer) Business Model Canvas (Strategyzer) Value Proposition Canvas (Strategyzer) Empathy Map Canvas Platform Design Toolkit

Oliver & Tim im Gespräch Wenn man bislang per Auftragsentwicklung eine Anwendung gebaut hat und sich von vermeintlichen Vertriebserfordernissen oder mächtigen B2B-Partern hat treiben lassen, reift oft der Wunsch: Lasst uns nun endlich ein klares Produkt formen! Wir besprechen in dieser Folge den steinigen Weg hin zu einer fokussierten Produktentwicklung. Oliver und Tim diskutieren zunächst, wie es zu diesem Wunsch, ein klares Produkt zu bauen kommt. Sie beleuchten die Symptome, die zu einer "verwurschtelten" Anwendung kommt, die quasi alles kann - aber nichts richtig gut. Welche Konsequenzen hat der Beschluss, nun "ein Produkt" zu bauen? Und sind die Auswirkungen einer solchen Entscheidungen den Organisationen überhaupt bewusst? Es werden Praktiken aufgezeigt, die helfen, aus einer Auftragsentwicklung kommend zu entscheiden, was ins künftige Produkt einfließen soll (und was nicht). Oliver und Tim betrachten auch die Stolperfallen, die man bei einem solchen Versuch beachten sollte und liefern am Ende ihre persönlichen wichtigsten Tipps im Umgang mit diesem Thema. Im Gespräch verweisen Oliver und Tim auf Themen und Praktiken, die wir bereits in früheren Episoden dieses Podcasts schon mal ausführlicher behandelt haben. Sofern ihr diese noch nicht kennt, dürfte es sich lohnen, diese beiden Folgen im Kontext zum aktuellen Thema nochmal in Ruhe anzuhören: Story Mapping nutzen, um über Outcome zu sprechen Wardley Mapping – Produktstrategie ist wie Schach 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.

Frank Wulfes im Gespräch mit Tim Wie kommen wir zu klugen Entscheidungen? Welche Entscheidungsverfahren gibt es? Und wie kann "Decision Poker" euch dabei helfen, zu guten Entscheidungen zu gelangen? Tim hat als Gast Frank Wulfes von Kurswechsel an seiner Seite. Frank hat zusammen mit seinen Kolleg:innen verschiedene Entscheidungsverfahren in eine spielerische Form überführt und so das sogenannte "Decision Poker" entwickelt. Es hilft bei der Frage: Wie kann es in einer Gruppe zu guten Entscheidungen kommen? Im Gespräch erläutert Frank zunächst, welche Entscheidungssituationen es geben kann - also welcher Kontext auf die Entscheidungsfindung wirkt. Auch ist wichtig zu betrachten, wer überhaupt entscheiden darf bzw. wer die "Richtigen" sind, die eine Fragestellung entscheiden sollten. Frank Wulfes erklärt die verschiedenen Entscheidungsverfahren, die Teil von Decision Poker sind: Konsens Mehrheitsentscheid Einwandintegration (Konsent) Widerstandsabfrage Beauftragter Fallentscheid (bzw. Konsultativer Einzelentscheid) Eigenmächtiger Einzelentscheid Top-Down Entscheidung Im Gespräch bezieht sich Frank Wulfes auf folgende Themen bzw. Quellen: Cynefin (https://de.wikipedia.org/wiki/Cynefin-Framework) Delegation Poker (https://management30.com/practice/delegation-poker/) Decision Poker (Erklärung: https://kurswechsel.jetzt/2020/05/14/decision-poker-spielerisch-reflektierte-entscheidungen-treffen/) Decision Poker (Download: https://kurswechsel.jetzt/wp-content/uploads/2020/05/Decision-Poker-by-Kurswechsel.pdf) Bücher: Buch-Tipp von Frank: https://decisions.companypirate.de/ Ergänzender Buch-Tipp von uns: Decisive von Chip und Dan Heath Podcast-Empfehlung: "Kurswechsel" Kontakt zur Frank Wulfes: Mail: frank.wulfes@kurswechsel.jetzt LinkedIn: https://www.linkedin.com/in/frank-wulfes-5b4802139/ 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 & Oliver im Gespräch Oft genug wird in Organisationen ein Product Owner Team implementiert. Aber steht denn nicht im Scrum Guide, dass die Product Owner Verantwortung nicht bei einem Komitee liegen darf? Dominique und Oliver diskutieren daher in dieser Episode die Vor- und Nachteile von Product Owner Teams. Anhand von Beispielen aus der eigenen Praxis zeigen Dominique & Oliver Gründe auf, die dazu führen können, in einer Produktentwicklung nicht nur mit einem Product Owner zu arbeiten. Dabei darf natürlich ein Blick auf Skalierungsframeworks wie Nexus, LeSS und SAFe nicht fehlen. Ein weiterer Schwerpunkt der Folge liegt darauf, zu reflektieren ob und wann PO Teams tatsächlich sinnvoll sein können. Welche Formen von Abreitsaufteilung unter den Product Owner sollte dabei gegeben sein. Und welche Rolle spielen die Developer und die Fachabteilungen in der Organisation, um weiterhin schnell und effizient Produktentscheidungen treffen zu können.

Carola Breuer im Gespräch mit Dominique Als Designer und Produktentwickler gestalten wird Produkte und Services und sind somit maßgeblich daran beteiligt, wie die Welt um uns herum aussieht. Wir haben dabei Verantwortung und Handlungsspielraum, zum Beispiel auch mal „nein" zu sagen. Somit tragen wir als Product Owner eine wichtige Verantwortung. Zeit also, dass wir einen Blick auf das Thema Diversity in der Produktentwicklung werfen und uns mit der Unterschiedlichkeit von Menschen beschäftigen. Für Orientierung sorgt in dieser Folge Carola Breuer (https://www.linkedin.com/in/carola-breuer/), die im Gespräch mit Dominique über die Herausforderungen und Möglichkeiten der Vielfältigkeit spricht. Carola zeigt uns ein paar Beispiele für gutes Design, wie beispielsweise Robotise jeevesoder auch "Q, the genderless voice". Wir hatten es erst auch nicht gedacht aber Pokemon Go benachteiligt beispielsweise bestimmte Menschen, da in ihren Lebensräumen weniger Spielinhalte vorkommen oder Twitter hatte eine Zeitlang einen Algorithmus, der Gesichter von weißen Menschen bevorzugt in die Vorschau packte. Obwohl wir als Product Owner sehr darauf aus sind, den größtmöglichen Nutzen für den eingesetzten Aufwand zu bekommen zeigt uns Carola, dass wir schon zu Beginn einfach und ohne große Mehrkosten Diversität berücksichtigen können. Als Tools und Methoden hat sie uns Extreme users (https://en.wikipedia.org/wiki/Extreme_users), Crossing cultural Chasms (https://designandculture.info/) und Designing for digital confidence (https://digitalconfidence.design/) mitgebracht. Dominique erwähnt in der Folge noch das Buch "Unsichtbare Frauen" (https://www.buch7.de/produkt/unsichtbare-frauen-caroline-criado-pere/1036808864?ean=9783442718870). Natürlich schließen wir wie immer mit ein paar wertvollen Tipps zum weitermachen und danken Carola sehr für ihre Erfahrungen und Expertise, die sie mit uns geteilt hat. Wir sind gespannt auf eure Erfahrungen zum Thema und freuen uns über jeden hilfreichen Kommentar!

Tim & Oliver im Gespräch Muss ich als Product Owner den Erfolg von User Stories messen? Reicht es nicht aus, wenn die Story "done" ist? Der Scrum Guide sagt jedenfalls nichts explizites dazu. Oliver und Tim klären daher zunächst mal die Frage, aus welcher Idee von Scrum man man diesen Bedarf ableiten könnte. Sie beziehen sich demnach auf das "Überprüfen" (engl.: inspect) als einer der drei Säulen der Scrum Theorie. Demnach soll man neben den Scrum Artefakten auch den Fortschritt in Richtung der vereinbarten Ziele häufig und sorgfältig überprüfen. Nun sind User Stories wahrlich keine Artefakte des Scrum Frameworks und so könnte man sagen, dass die Akzeptanzkriterien einer Story in Verbindung mit der Definition of Done gut genug sind, um den Erfolg einer User Story zu bewerten. Darüber hinaus, begutachten wir ja auch im Sprint Review das Product Increment. Kann dies vielleicht als Erfolgsmessung herhalten? In der Reflektion sehen Tim und Oliver hier das Problem, dass ich am Ende eines Sprints in der Regel noch nicht genau beziffern kann, ob z.B. ein erfolgreich gebautes und evtl. sogar bereits ausgeliefertes Feature wirklich schon etwas bewirkt und damit Wert liefert. Also müssen wir uns fragen: was heißt denn hier überhaupt "Erfolg" von User Stories messen? Schnell kommt man auf eine Outcome-Betrachtung und es wird deutlich, dass ich einige zeitverzögerte Wirkungen von ausgelieferten Features beachten muss. Wir müssen also sogenannte "Lagging Indicators" begutachten und messen. Aber wie kann das in Scrum klappen und wie kann ich es vor allem organisieren, um den Erfolg von User Stories messen zu können, wenn denn der Outcome oft erst zeitverzögert sichtbar wird? Hierzu stellen Oliver und Tim einige Ideen vor und geben Anregungen für die Umsetzung. Im Lauf des Gesprächs wird an verschiedenen Stellen immer mal wieder Bezug auf andere Folgen unseres Podcasts genommen. Wenn Du also die folgenden, zum Teil älteren, Episoden noch nicht kennst bzw. dir die Themen in der Tiefe noch nicht so vertraut sind, könnte es sich lohnen, sie dir jetzt mal anzuhören. Erfolgreich mit User Stories arbeiten Akzeptanzkriterien richtig einsetzen Das Product Goal und seine Bedeutung für Product Owner Agile Product Roadmaps Das Sprint-Ziel als Product Owner nutzen Als Product Owner im Sprint Review 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.

Lars Böhnke im Gespräch mit Tim Lars Böhnke ist sicherlich ein Paradebeispiel für einen Produktmanager im Startup. Dabei ist er gelernter Buchhalter. Das wiederum kann einem aber auch ganz gut helfen, wenn man wie Lars für das Produktmanagement des Startups (bzw. inzwischen fast schon ScaleUp) candis.io zuständig ist. CANDIS erleichtert die Abrechnung und revolutioniert das Rechnungsmanagement, inklusive prüfungssicherer Anbindung an DATEV usw. Macht das Spaß, als Produktmanager im Startup für so ein "trockenes" Thema zu arbeiten? Lars schon! Denn warum es ihm soviel Spaß macht, wird euch nach dieser Podcast-Folge auch klar sein. Wer von uns kann in der Praxis schon wirklich behaupten, dass er/sie durchschnittlich rund zehnmal pro Woche ausführlich mit Kunden spricht, um neue Hypothesen zu validieren und Nutzerprobleme besser zu verstehen? Die Haltung in Bezug auf Kundenfeedback und Product Discovery, die uns Lars im Gespräch rübergebracht hat, steckt nicht nur an, sondern macht einfach gute Laune und gibt echt gute Anregungen. In ähnlichem Kontext hatte uns Kerstin Neumann in der Episode auch schon "Impulse für ganzheitliche Kundenzentrierung" aus dem Startup Leben gegeben. Hört euch das im Zweifel auch nochmal an. Lars empfiehlt im Gespräch u.a. folgende Quellen bzw. beruft sich auf folgende Autoren: Marty Cagan: The Four Big Risks (Blogartikel) Teresa Torres: Continuous Discovery Habits (Buch) Alan Klement auf Revealed: Jobs to be Done. Understanding Needs. Predicting Adoption (kostenfreies Online-Buch) Wer mehr über Lars erfahren möchte bzw. mit ihm in den Austausch kommen erreicht ihn sehr gut auf Twitter (@larsboehnke). Ansonsten per Mail (lars@candis.io) oder auf LinkedIn (https://www.linkedin.com/in/lboehnke/)

Dominique und Tim im Gespräch Technische Schulden mag wahrscheinlich keiner. Dennoch gehen wir sie gelegentlich ein, um ein wichtiges Ziel zu erreichen. In dieser Folge sprechen Dominique und Tim über die Herausforderungen, die technische Schulden für Product Owner mitbringen und wie man mit den Schulden umgehen kann. Sie kommen nicht umher und sprechen erst einmal darüber, was technische Schulden eigentlich sind und stellen schnell fest, dass Dominique und Tim selbst schon kein einheitliches Verständnis haben. Trotz unterschiedlicher Verständnisse zeigen sich durch Schulden Probleme in der Produktentwicklung, die auch Product Owner betreffen. Es stellt sich zum Beispiel die Frage, ob man ein eigenes Backlog für technische Schulden haben sollte oder wie man sie sich bewusst und sichtbar macht. Aber auch ist es für Product Owner wichtig zu verstehen wie technische Schulden überhaupt entstehen. Die beiden schließen mit Tipps, wie Product Owner gut mit technischer Schuld umgehen können, die die beiden gute Erfahrungen gemacht haben. 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.

Boris Steiner & Glenn Lamming im Gespräch mit Tim Evidence-Based Management (EBM) ist ein Denkansatz (Framework), welcher euch helfen kann, in der Organisation über den Wert eurer gelieferten Produktentwicklungen zu reflektieren. Mit EBM kann man diesen Wert messen, managen und so versuchen, ihn kontinuierlich zu steigern. Beim EBM wird die Verbesserung von Ergebnissen, die Reduzierung von Risiken und die Optimierung von Investitionen fokussiert. Das Denkmodell basiert auf den Arbeiten von Ken Schwaber und Scrum.org. Dort findet ihr auch die meisten Ressourcen zu EBM. Aus diesem Grund ist EBM auch Teil der Lerninhalte der Product Owner Trainings der Scrum.org. Unsere Gäste in dieser Episode, Boris Steiner und Glenn Lamming, sind beide Professional Scrum Trainer bei Scrum.org. Glenn und Boris geben v.a. gerne zusammen als Team ihre Trainings und insbesondere Product Owner Trainings. Sie sind in ihrer Arbeit sehr auf Outcome orientiert und ausgewiesene Experten für Evidence-Based Management. EBM basiert auf der Betrachtung von vier Key Value Areas: des Unrealized Value (UV) - Zeigt den Wert an, der dem Kunden oder Benutzer heute geliefert wird des Current Value (CV) - der Wert, der durch die Erfüllung aller potenziellen Bedürfnisse von Kunden oder Anwendern realisiert werden könnte der Ability to Innovate (A2I) - Misst die Fähigkeit, eine neue Funktionalität zu liefern, die die Bedürfnisse von Kunden oder Anwendern besser erfüllen könnte der Time to Market (T2M) - Bewertet die Fähigkeit, neue Funktionalitäten, Dienstleistungen oder Produkte schnell liefern zu können Wenn ihr mit Boris und Glenn in Kontakt kommen wollt bzw. an ihren Trainings interessiert seid, bekommt ihr über folgende Wege Kontakt zu den beiden. Boris Steiner: https://www.linkedin.com/in/borissteiner/ bzw. https://www.borissteiner.com/ Glenn Lamming: https://www.linkedin.com/in/glennlamming/ bzw. https://www.glennlamming.com/ Literaturempfehlungen: Kurzeinführung zu EBM bei Scrum.org The Evidence-Based Management Guide von Scrum.org Ian Mitchell: Becoming Agile: Evidence Based Management Agile Shift - Why On-Time, On-Budget Doesn't Work (Video) Todd Mitchell: Lessons Learned from Implementing Evidence-Based Management Kurt Bittner: Measuring Agility Kurt Bittner: When are SMART goals not-so-smart? Diese Episode steht auch in Zusammenhang zur Folge mit Tim Herbig "Outcome Goals und Product Discovery". Falls ihr die noch nicht gehört habt, könnte es sich lohnen, dies jetzt nachzuholen.

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.