Die Produktwerker

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.