Tim spricht mit Dominik Kress über dessen Erfahrung auf seiner Lernreise vom Entwickler zum Product Owner. Dominik hat ist von Hause aus lange Jahre Software Engineer und liebt es auch heute noch zu Programmieren. Aber er konnte sich auch schon immer für die (Software)-Produkte begeistern, an denen er als Entwickler arbeitete. So war es irgendwann ein logischer Schritt, auch schon aus dem Team heraus (eher) technische User Stories zu erstellen und so das Produkt an einigen Ecken mit zu gestalten. Vor einer Weile ergab sich dann durch einen Teamwechsel die Möglichkeit, die Product Owner Rolle für ein technisches Produkt (eine Cloud Runtime) komplett zu übernehmen. Im Gespräch interessiert Tim daher die Frage, was Dominik bei dem Wechsel in die andere Rolle überrascht hat. Vermisst er das entwickeln? Und wie schafft es Dominik, nicht in das (technische) "WIE" des Teams einzugreifen? Letztlich geht es um die Frage, ob Product Owner mit einem Entwickler-Background mit dem ein oder anderen Thema anders umgehen. Gibt es einen größeren Fokus auf technische Exzellenz und werden technische Folgen eher vermieden? Und wie wird er von den Teammitgliedern oder auch Stakeholdern gesehen? Interessant ist auch die Frage, ob sich Dominik nach dem aktuellen sehr technischen Produkt auch als Product Owner für ein eher fach-nahes Produkt sehen würde. Am Ende gibt Dominik natürlich noch Tipps für andere Entwickler, die sich vielleicht mal in der Product Owner Rolle ausprobieren möchten. Freut euch auf einen spannenden und kurzweiligen Erfahrungsbericht! Wenn ihr mit Dominik Kress in Kontakt treten wollt, freut er sich über eure Nachricht per Mail: dominik.kress@mail.schwarz Im Zusammenhang mit einem Bereich der Diskussion in dieser Episode ist auch die Folge 73 rund um Technische Schulden empfehlenswert: - Technische Schulden und wie wir als Product Owner damit umgehen Welche Erfahrungen hast du vielleicht selbst als Entwickler:in auf dem Weg zur Product Owner:in erlebt? Welche Tipps hast Du für andere? Oder überlegst du diesen Weg noch zu gehen und stellst dir noch Fragen, die nicht beantwortet wurden? Wir freuen uns, wenn du deine eigenen Erfahrungen, Tipps oder Fragen mit uns in einem Kommentar auf unserer Webseite (https://produktwerker.de/) oder auf unserer Produktwerker LinkedIn-Seite (https://www.linkedin.com/company/produktwerker/) teilst. Wenn euch dieser Podcast gefällt, freuen wir uns auch über eine positive Bewertung in eurer Podcast App oder als Feedback per Mail an podcast@produktwerker.de oder via Instagram oder Twitter (@produktwerker).

Die Produktwerker

Vom Entwickler zum Produkt Owner

LeSS zwingt den Product Owner, seinen Fokus auf sie 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: https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf - Spotify Engineering Culture, dieses Video wird üblicherweise als Video über das "Spotify-Model" referenziert: https://blog.crisp.se/2014/03/27/henrikkniberg/spotify-engineering-culture-part-1 - Henrik Kniberg: No, I didn’t invent the Spotify model: https://blog.crisp.se/2015/06/07/henrikkniberg/no-i-didnt-invent-the-spotify-model - Heutige Sicht von Henrik Kniberg auf Scrum@Scale im Vergleich zum "Spotify-Model": https://www.scruminc.com/spotify-model-scrum-at-scale/ - Die offizielle Beschreibung von LeSS mit allen Details, die ihr über das (De)Skalierungs-Framework LeSS wissen müsst: https://less.works/ Wenn ihr mit Eike in Kontakt treten wollt, freut er sich über eure Nachricht auf folgenden Kanälen: Eike Gehler Mail : eike@aykey.de, LinkedIn (https://linkedin.com/in/eike-gehler-a2479968/) oder Web (https://aykey.de/) 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 (https://produktwerker.de/) oder auf unserer Produktwerker LinkedIn-Seite (https://www.linkedin.com/company/produktwerker/) teilst.

LeSS aus Product Owner Sicht und aktuelle Skalierungstrends

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 (https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/) - 10 powerful strategies for breaking down Product Backlog Items in Scrum (with cheatsheet) von Christiaan Verwijs (https://link.medium.com/z8nCpZSyx9) - Twenty Ways to Split Stories von Bill Wake (https://xp123.com/articles/twenty-ways-to-split-stories/) - User Story Splitting Flowchart von Richard Lawrence. Deutsche Fassung übersetzt von Kai Simons (https://www.ksimons.de/2012/09/user-stories-einfach-teilen-mit-dem-user-story-splitting-flowchart/) - S.P.I.D.R. Approach von Mike Cohn (https://www.mountaingoatsoftware.com/exclusive spidr-poster-download) 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 (https://produktwerker.de/user-story-splitting/) 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.

User Story Splitting: Wie geht das "richtig"?

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?

Das hätten wir gerne früher gewusst...

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: 1. Product Owner ist nicht Teil des Teams oder wird nicht so wahrgenommen 2. Product Owner übernimmt Scrum Master Aufgaben 3. Das Fehlen einer Produktvision 4. Fehlendes Wissen über Wert & Kosten 5. 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 "Mein Freund der Scrum Master" mit Steffi Götten, weil wir dort einige Lösungsansätze zur Überwindung der NoGos besprochen haben.

Product Owner No Gos

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/

Wie gehe ich als Product Owner mit Bugs um?

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.

Coaching von Product Ownern

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.

Wenn ein Product Owner als Teammitglied mitarbeitet

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)] (https://www.strategyzer.com/books) [Business Model Canvas (Strategyzer)](https://www.strategyzer.com/canvas/business-model-canvas) [Value Proposition Canvas (Strategyzer)](https://www.strategyzer.com/canvas/value-proposition-canvas) [Empathy Map Canvas](https://medium.com/the-xplane-collection/updated-empathy-map-canvas-46df22df3c8a) [Platform Design Toolkit](https://platformdesigntoolkit.com/toolkit/)

Geschäftsmodelle entwickeln als Product Owner

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.

Aus auftragsgetriebener Anwendung ein Produkt entwickeln

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

Kluge Entscheidungen treffen mit Decision Poker

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.

Das Product Owner Team

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!

Diversity in der Produktentwicklung

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.

Wie können wir den Erfolg von User Stories messen?

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

Produktmanager in einem Startup - Erfahrungsbericht eines Buchhalters

Im Podcast der Produktwerker besprechen wir Themen rund um die Rolle des Product Owners. Dazu tauschen wir uns nicht nur untereinander aus, sondern sprechen auch mit interessanten Gesprächspartnern aus allen möglichen Themenbereichen von Product Ownern. Die Produktwerker sind Tim Klein (@produktwerkCGN), Oliver Winter (@oliwin) und Dominique Winter (@designik). Als Experten für Produktentwicklungen haben wir uns in der agilen Community Kölns kennen und schätzen gelernt. Wir drei wollen die Kompetenz von Product Ownern und Produktorganisationen fördern, bessere Produkte und Services zu entwickeln. Wir freuen uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker.

hubhopper

Die Produktwerker

hubhopper