Die Produktwerker

Peter Rochel im Gespräch mit Tim Mit der "Jobs-to-Be-Done"-Theorie (JTBD) lassen sich unterschiedliche Dimensionen von Kundenbedürfnissen wunderbar erklären. So kann man schön unterscheiden, welche Bedürfnisse das Produkt oder ein Service bedient. Oder, um es im Wording der Jobs-to-Be-Done Theorie zu sagen: für die Erledigung welchen Jobs dieses Produkt vom Nutzer beauftragt wird. Unser Gast Peter Rochel ist zusammen mit Eckhart Böhme sicherlich das führende Gespann, das es im deutschsprachigen Raum rund um die JTBD-Theorie gibt. Aber die beiden halten sich nicht mit der Theorie auf, sondern nutzen sie in ihrer praktischen Innovationsarbeit und Produktentwicklung. Und genau darum geht diese Podcast-Folge. Zunächst erklären wir natürlich erst noch mal Herkunft, Aufbau und Idee der Jobs-to-Be-Done Theorie. Aber dann geht es vor allem um die Anwendungen in den sogenannten JTBD-Interviews. Beispiele solcher Interviews könnt ihr im Podcast "Innovate+Upgrade" von Peter Rochel auch mal komplett anhören - echt spannend. Und im letzten Teil stellt Peter auch noch dass von ihm und Eckhart entwickelte spannende "Wheel of Progress®" vor. Das ganze ist ein super hilfreicher Canvas, um die JTBD-Interviews sehr strukturiert dokumentieren zu können. So macht man z.B. alle Kräfte, den jeweiligen Kontext und den dem Produkt (oder Service) zugeschriebenen erstrebten Fortschritt explizit. Wertvolle Quellen rund um "Jobs-to-Be-Done": JTBD.de – die deutschsprachige Community für die Jobs to Be Done (JTBD)-Theorie, inkl. einer guten Erklärung der JTBD-Theorie Clayton M. Christensen: Besser als der Zufall: "Jobs to Be Done" - die Strategie für erfolgreiche Innovation (Original: Competing Against Luck) Das Original-Video zum bekannten "Milkshake"-Beispiel von Clayton M. Christensen Shot: Was ist ein JTBD? (Kurzerklärung). Alle Shots gibt's hier Webinar von Peter Rochel bei Mr. Kundenbrille Kompakte Beispiele zu JTBD-Kundeninterviews im Podcast-Format Wenn ihr Peters Aktivitäten weiter verfolgen, direkten Kontakt zu Peter Rochel aufnehmen wollt oder er euch in euren Innovationsherausforderungen helfen kann, geht das für zahlreiche Wege: Web, Facebook, Twitter, LinkedIn, Xing oder per Mail. Kanntet ihr "Jobs-to-Be-Done" schon oder und nutzt ihr sogar schon JTBD-Interviews? Oder wie kommt ihr den wahren Kundenbedürfnissen ansonsten auf die Schliche? Lasst uns gerne an euren Erfahrungen oder auch eurer Kritik teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite.

Tim im Gespräch mit Oliver Was unterscheidet eigentlich gute Product Owner von sehr guten Product Ownern? Welche Fähigkeiten und Fertigkeiten zeichnen die sehr guten Product Owner aus? Oder sollte man diese Fragen erst gar nicht stellen, weil es keine zufriedenstellende Antwort darauf geben kann. Tim und Oliver wagen die Fragen trotzdem zu stellen. Sie versuchen in dieser Podcastfolge vor allem auf die Human Skill und Fähigkeiten sehr guter Product Owner zu schauen. Die beiden beleuchten neben ganz grundsätzlichen Aspekten wie Haltung, Werte, Empathie auch den organistatorischen Kontext, in dem diese Aspekte unterschiedlich bedeutsam sind. Auf diesen einleitenden Gedanken aufbauend vertiefen Oliver und Tim ihr Gespräch vor allem in den Themenschwerpunkten Kommunikation, Umsetzung, Forschung und Organisation. Das Resultat sind viele kleine Impulse, die dich deine eigene Einstellung und Verhalten in der eigenen Product Owner Rolle sicher reflektieren lassen. Von uns in dieser Podcast-Folge erwähnte Quellen: Product Management in practice - Matt LeMay Geben & Nehmen - Adam Grant Strong Product People - Petra Wille

Dominique im Gespräch mit Michael Schopp Diese Folge bietet dir wieder einen interessanten Erfahrungsbericht. Unser Gast Michael Schopp spricht mit Dominique über seinen Werdegang vom Product Owner zum Steuerberater, also - verglichen mit unseren bisherigen Gästen - einer eher untypischen Laufbahn. Michael beschreibt, wie er Product Owner wurde, warum ihn das damals reizte und was er aus dieser Zeit für seine jetzige Selbstständigkeit mitgenommen hat. Michael gibt uns einen tieferen Einblick, wie Produkte für Steuererklärungen erzeugt werden und welche Herausforderungen dabei existieren. Darüber hinaus berühren die beiden vor allem die Aspekte der Kundenorientierung und der Führung. Heute ist Michael Inhaber der Steuerberatung Schopp (https://steuerberatung-schopp.de). Wenn auch ihr mal Lust habt von euren ungewöhnlichen Werdegang zum Product Owner und darüber hinaus zu berichten, wendet euch gerne an uns (info@produktwerker.de). Außerdem freuen wir uns über Feedback von euch. Gerne auch im Podcatcher eurer Wahl.

Dominique im Gespräch mit Oliver In dieser Folge unseres Product Owner Podcast sprechen Dominique & Oliver über die agile Praktik Magic Estimation. Und natürlich legen sie den Fokus ihrer Diskussion auf den besonderen Nutzen dieser Schätzmethode für Produkt Owner. Die Idee geht ursprünglich auf einen Vorschlag von Lowell Lindstrom aus dem Jahr 2008 zurück. Er nannte seine Idee „Affinity Estimation“. Boris Gloger griff den Ansatz auf und überarbeitete diesen zu Magic Estimation. Das Magische: sehr viele Product Backlog Items in sehr kurzer Zeit durchschätzen, um beispielsweise für ein bestimmtes Release eine grobe Idee zu einem Termin abgeben zu können. Dominique erläutert, wie er eine solche magische Schätzsession vorbereitet und dann mit dem Team durchführt. Er teilt viele hilfreiche Tipps und Tricks, die auch die Aufgaben eines Product Owners nach einer solchen Session betreffen: Wir überführe ich die Schätzungen ins Product Backlog? Und warum macht es Sinn, die Ergebnisse der Schätzungen im Product Backlog besonders zu markieren? Links zu Artikeln, um das Wissen zu vertiefen: Affinity Estimation Estimation: A kind of magic Magic Estimation (2010)

Peter Beck im Gespräch mit Oliver Als Scrum Product Owner nutze ich das Scrum Framework, um ein möglichst erfolgreiches Produkt zu entwickeln. Was ist aber mit dem dritten Teil „Owner“ konkret gemeint? Über diese Frage und damit auch die Rechte und Pflichten von Product Ownership spricht Peter „Pit“ Beck von Das Scrum Team mit Oliver in dieser Folge unseres Podcast. Pit erklärt Ownership mit der „Fähigkeit, den Besitz zu verwalten“. Also sollte ein Scrum Product Owner die Interessen des Besitzes wahren und im Sinne der Eigentümer handeln. Leider sind wir von diesem Verständnis in großen Organisationen und Konzernen meistens sehr weit entfernt. Rückhalt für POs aus der unternehmerischen Führung heraus ist eher in kleinen Unternehmen und Startups zu finden. Oliver und Pit diskutieren, wie weit die Ownership sinnvollerweise ausgestaltest sein sollte, damit der Product Owner auch wirklich erfolgreich sein kann. Einen weiteren Schwerpunkt legen die beiden auf Haltung und Fähigkeiten, die es braucht, um unternehmerisch tätig zu werden und das unternehmerische Denken auch ins Team zu bekommen. Diese Verantwortung muss man aber auch voll, aushalten können. Denn Ownership verpflichtet. Mit dem Eigentum kommen Macht und Verpflichtung, mit der ich nicht alles machen kann. Product Owner haben besondere Rechte und Pflichten. Daher sollte auch jede(r) selber eine bewusste Entscheidung treffen, ob man für die Übernahme bereit ist und diese auch will. Neben Tipps & Tricks reflektieren Pit und Oliver, wie es gelingen kann, mehr Product Owner mit wirklicher Ownership entwickeln zu können.

Dominique & Tim im Gespräch Wenn es Zeit wird den eigenen Kontext zu wechseln, dann müssen wir meist unser Produkt an jemanden übergeben. In dieser Folge beschäftigen sich Dominique und Tim damit, was es bei der Übergabe der Produktverantwortung an nachfolgende Product Owner zu beachten gilt und wie man dabei nach ihrer Erfahrung nach gut vorgehen kann. In der Folge verweisen wir auf zwei andere Folgen. Für Bessere Entscheidungen dun Delegation verweisen wir auf die Folge zum Decision Poker (https://produktwerker.de/entscheidungen-treffen-decision-poker/) und natürlich dürfen wir nicht vergessen, dass uns bei der Übergabe auch der Scrum Master / die Scrum Masterin helfen kann (https://produktwerker.de/dein-freund-der-scrum-master/). Wie immer freuen wir uns über eure Erfahrungen und Tipps, wie man die Verantwortung als Product Owner am besten übergeben kann. Gerne auch Erfahrungen, wie es überhaupt nicht funktioniert… also außer ganz auf eine Übergabe zu verzichten. ;-)

Helen Sedlmeier im Gespräch mit Tim Gerade zu Beginn einer Produktentwicklung ist die Unsicherheit über das "Was", das "Wie" und den Produktkontext oft unklar und unsicher - jedenfalls dann, wenn wir Produkte in einem komplexen Problemumfeld entwickeln. Hier setzt das sogenannte "Inception Deck" an. Die Vorlage gibt eine Struktur, um gemeinsam die Ausgangslage, den bislang verstandenen Nutzer- und Kundenbedarf zu beschreiben und somit ein gemeinsames Verständnis der Herausforderung explizit zu machen. Letztlich ist dies auch die Aufgabe des/der Product Owner:in hier für Klarheit zu sorgen. Oder anders gesagt: das Inception Deck kann gerade beim Start einer Produktentwicklung einen guten Rahmen für ein gelungenes Erwartungsmanagement schaffen. Und so etwas hilft der PO Rolle in der weiteren Arbeit mit Stakeholdern natürlich sehr. Alleine weil man sich in aufkommenden Diskussionen immer auf die gemeinsam im Inception Deck erarbeitete und zum aktuellen Zeitpunkt "gültige" Sicht berufen kann. Sicherlich ist auch das nur der "letzte Stand unseres Irrtums". Konkret besteht das Inception Deck aus einer Vorlage von zehn Fragestellungen, die gemeinsam besprochen oder erarbeitet werden sollten, bevor man in die Product Delivery Phase der operativen Umsetzung startet - oder zumindest sollte dies parallel gleich am Anfang geschehen. Die ersten fünf Fragen drehen sich um das "Wozu machen wir das?" („Why"), die Schritte sechs bis zehn um das "Wie machen wir das?" („How"). Im Gespräch erläutert Helen Sedlmeier die einzelnen Punkte und erklärt auch, wie sie das Inception Deck einsetzt und wie es für sie selbst, insbesondere als Externe Product Ownerin, besonders hilfreich ist. Die Vorlage selbst gibt es als PowerPoint Template – zu finden auf The Agile Warrior. Zum Thema Inception Deck hat Helen folgende Quellen empfohlen: Artikel von Helen im Mayflower Blog Neal Ford, Rebecca Parsons, Patrick Kua: Building Evolutionary Architectures: Support Constant Change Jonathan Rasmusson: The Agile Samurai - How Agile Masters Deliver Great Software Im Zusammenhang mit dieser Episode möchten wir euch auch diese Folgen ans Herz legen: Wie die Produktvision hilft, Product Ownern eine Richtung zu geben Welche Aufgaben gehören zur Product Owner Rolle? Wenn ihr weitere Fragen zum Inception Deck oder zu anderen Themen an Helen Sedlmeier habt, erreicht ihr sie am Besten über das LinkedIn-Profil von Helen. Sie freut sich über eure Kontaktaufnahme. Kanntet und nutzt ihr das Inception Deck vielleicht sogar schon? Oder wie klärt ihr das mit dem Erwartungsmanagement im Umfeld - gerade zum Beginn eurer Produktentwicklung? Lasst uns gerne an euren Erfahrungen oder auch eurer Kritik teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite.

Dominique & Oliver im Gespräch „Nein sagen ist eine Kernkompetenz eines jeden Product Owners.“ Diese Aussage wird häufig wie ein Mantra unreflektiert wiederholt und an uns Produkt Owner kommuniziert. Oliver und Dominique versuchen in dieser Folge unseres Product Owner Podcast einmal kritisch auf die Aussage zu gucken. Und die beiden nähern sich generell der Herausforderung des Neinsagens. Nachdem Oliver & Dominique sich darüber ausgetauscht haben, ob und warum Nein sagen wichtig ist, teilen die beide Situationen aus ihrer eigenen Historie, in denen das Wort ihnen persönlich schwer gefallen ist. Intensiv reflektieren sie, was man bei einer Ablehnung von Wünschen oder Features beachten sollte und welche Arten von Nein sagen unterschieden werden können. Spannend ist der Gedanke, ob wir als Produkt Owner nicht viel mehr über das JA sagen nachdenken sollten. Dann zu oft Nein zu kommunizieren ist evtl nur ein Umweg zu mehr Fokus und es kann einem auf Dauer auch emotional nicht gut tun. Wie in jeder Folge, schließen Dominique & Oliver mit Tipps und Tricks das Thema ab.

Stefan Roock im Gespräch mit Tim Lange Zeit waren Business Storys in Vergessenheit geraten. Nach gut 20 Jahren erinnert Stefan Roock nun wieder an diese wertvolle Praktik im Rahmen outcome-orientierter Produktentwicklung. Er verhilft ihnen somit zur Renaissance. Aus diesem Grunde ist Stefan heute zu Gast und diskutiert mit Tim die Idee, Wirkung und Struktur von Business Stories. Eine Business Story beschreibt eine Wirkung, die wir für Kunden und das eigene Unternehmen erzielen wollen. Bei Business Storys geht es also um wirksame Agilität, genauer gesagt rücken sie neben der Wirksamkeit für Nutzer (wie bei User Stories) auch den Effekt und die Wirkung für das eigene Unternehmen in den Fokus. Sie können somit helfen auf abstrakterem Level Business Ziele zu formulieren, die in der weiteren Arbeit dann noch in User Stories runter gebrochen werden müssen. In wiefern dies dann Epics oder sogar Product Goals sein könnten, diskutieren Stefan und Tim in dieser Episode. Auch die Nähe zu OKR (Objectives and Key Results) wird in dieser Folge aufgegriffen. Als Quellen zum Thema Business Stories können wir empfehlen: Blog Artikel von it-agile: Was ist eine Business Story? (inkl. Download des besprochenen Business Story Templates) Blog Artikel von Stefan Roock und Ulf Mewe: Wirklich wirkungsvolle Agilität mit Business Storys Talk von Stefan auf der Tools4AgileTeams 2021: Business Stories - wirksam wirklich wertvolle Produkte entwickeln Im Zusammenhang mit dieser Episode möchten wir euch auch diese Folgen ans Herz legen: Outcome Goals & Product Discovery Das Product Goal und seine Bedeutung für Product Owner Wie können wir den Erfolg von User Stories messen Nutzt ihr bereits Business Stories? Oder wie sorgt ihr ansonsten dafür, dass neben dem Outcome für die Nutzer:innen auch der Business Impact Beachtung in der Produktentwicklung findet? Lasst uns gerne an euren Experimenten und Erkenntnissen teilhaben. Wir freuen uns, wenn du deine eigenen Erfahrungen mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite.

Dominique, Oliver & Tim im Gespräch Als Karrierepfad bezeichnet man eine von Arbeitgebern angebotene Karriereoption, die von einem definierten Einstiegspunkt im Regelfall zu einer berechenbaren und stabilen Karriere führen soll. Aber welchen Karrierepfad werde ich als Product Owner:in beschreiten? Und ist die Verantwortlichkeit als Product Owner:in überhaupt Teil (m)einer Karriere? Muss ich als Product Owner:in überhaupt weiter Karriere machen? In dieser Folge reflektieren wir zu dritt, welche Karrierepfade ich als Product Owner:in beschreiten kann. Tim, Dominique und Oliver teilen, welche unterschiedlichen Optionen sie in ihrer eigenen Karriere bislang wahrgenommen oder selber beschritten haben. Grundsätzlich kann man Karrieren in der Product Owner Rolle oder eine aus der Product Owner Rolle hinaus unterscheiden. Während wir beispielsweise Stufen in Form von Junior, Senior & Lead PO kritisch einordnen, kann man mit der wachsenden Bedeutung meines Produktes durchaus sinnvolle Schritte auf meinem Karrierepfad gehen. Zu den Optionen, sich aus der Rolle hinaus zu entwickeln, haben wir in den letzten Monaten einige sehr interessante Folgen mit Erfahrungsberichten veröffentlicht, z.B.: Meine Erfahrungen als Chief Product Owner - mit Niklas Trenn (STHIL) Von der Führungskraft zurück zum Product Owner - mit Jan an de Meulen (Congstar) Von Product Ownership zu Product Leadership – ein Erfahrungsbericht - mit Christiane Mehling (RTL+) Meine Rolle als Teamleiter von Product Ownern – Ein Erfahrungsbericht - mit Hendrik Neumann Meine Rolle als Chief Product Owner - David Yasli (REWE Digital)