Die Produktwerker

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.

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