by Tim Klein, Dominique Winter, Oliver Winter
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 [email protected] oder via Twitter an @produktwerker.
Language
🇩🇪
Publishing Since
12/16/2019
Email Addresses
1 available
Phone Numbers
0 available
April 21, 2025
Viele Teams liefern solide Features, füllen regelmäßig ihr Sprint-Backlog und schaffen es, in kurzen Zyklen Output zu produzieren. Doch was am Ende häufig fehlt, ist die entscheidende Frage: Welche Wirkung hat das eigentlich beim Nutzer? Genau darum geht es in dieser Folge. Oliver und Tim nehmen sich die drei häufig vermischten Begriffe Output, Outcome und Impact vor und ordnen sie praxisnah ein – nicht als Buzzwords, sondern als Grundlage sinnvoller Produktarbeit. Output ist schnell sichtbar. Ein Release ist gemacht, ein Feature live. Doch das allein reicht nicht. Outcome meint die Veränderung, die daraus entsteht – idealerweise beim Nutzer. Ein Verhalten, das sich ändert. Eine Aufgabe, die leichter fällt. Ein Problem, das nicht mehr existiert. Und genau darum sollte es gehen: Wirkung vor Lieferung. Es ist diese Wirkung, der wir in der Produktentwicklung hinterherlaufen sollten – nicht nur dem fertigen Feature. Was das schwierig macht: Outcome ist oft nicht sofort greifbar. Er entsteht nicht exakt in dem Moment, in dem ein Button live geht oder ein Flow angepasst wird. Es braucht Beobachtung, echtes Nutzerverständnis, Hypothesen und die Bereitschaft, Wirkung als Lernfeld zu begreifen. Viele Teams bleiben beim Output stehen, weil er einfacher zu messen ist. Doch wer wirklich wissen will, ob ein Produkt erfolgreich ist, muss sich auf Outcome fokussieren – auch wenn das bedeutet, Unsicherheit auszuhalten. Gleichzeitig braucht es gute Grundlagen, denn ohne verlässlichen, qualitativ hochwertigen Output gibt es auch keinen Outcome. Doch die reine Lieferung darf nicht zum Selbstzweck werden. Es geht darum, das Produkt so weiterzuentwickeln, dass es tatsächlich etwas verändert – beim Menschen, der es nutzt, und letztlich auch beim Unternehmen, das es anbietet. Hier kommt der Impact ins Spiel. Denn wenn ein Feature genutzt wird, weil es einen echten Unterschied macht, dann kann daraus auch ein (positives) Geschäftsergebnis entstehen. Oliver und Tim zeigen in der Folge, wie Product Owner diese Perspektive einnehmen können – nicht als dogmatischen Rollenwechsel, sondern als bewussten Schritt. Outcome-orientiertes Arbeiten bedeutet, sich stärker mit Nutzerverhalten zu beschäftigen, Hypothesen zu formulieren, die Wirkung von Features zu hinterfragen und gemeinsam im Team zu reflektieren, was funktioniert – und was nicht. Es geht darum, sich vom Projektdenken zu lösen, Raum für Lernen zu schaffen und sich nicht nur an der Anzahl der ausgelieferten Features zu messen, sondern an der Veränderung, die sie bewirken. Outcome ist aber nicht immer eindeutig zuzuordnen. Manchmal braucht es Geduld, manchmal bleibt Wirkung aus, obwohl der Output gut war. Doch genau das ist der Kern moderner Produktentwicklung. Es geht nicht um Planbarkeit, sondern um Verantwortung für Wirkung. Und wer als Product Owner diese Wirkung gestalten will, kommt um den Outcome nicht herum. Erwähntes Video zur Erklärung der Begriffe: - The Mindset That Kills Product Thinking by Jeff Patton Frühere Folgen, auf die verwiesen wird: - Mit "Jobs to Be Done"-Interviews zum besseren Kundenverständnis - Finance Talk: Warum die Zahlen für deine Karriere wichtig sind - Agile Product Roadmaps - Nutze Story Mapping, um mit Stakeholdern über Outcome zu sprechen - Impact Mapping – was zahlt wirklich auf unser Business Ziel ein? - Outcome Goals & Product Discovery (Tim Herbig) Wie setzt du diese Begriffe ein? Wie erklärst du sie deinem Team und deinem Umfeld? Hast du weitere Tipps, um besser Outcome und Impact liefern zu können? Wir Produktwerker freuen uns, wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite.
April 14, 2025
Die Verantwortung als Product Owner:in ist nicht mehr das, was sie mal war – und genau darin liegt die Herausforderung, denn Veränderung passiert. Sie kommt schleichend, manchmal unbemerkt, manchmal mit Ansage. In jedem Fall aber erfordert sie Orientierung, Mut und die Bereitschaft, sich selbst zu hinterfragen. In dieser Folge sprechen Annette Greil, Maik Seyfert und Dominique über genau diesen Wandel – und darüber, wie man ihn aktiv gestalten kann. Die Veränderung betrifft dabei nicht nur Aufgaben, sondern das gesamte Selbstverständnis der Rolle. Während Product Owner:innen früher oft stark in der Delivery verankert waren, verschiebt sich der Schwerpunkt zunehmend in Richtung Discovery, Strategie und Business-Verantwortung. Das klingt erst einmal nach einem echten Upgrade. Doch mit der erweiterten Verantwortung kommen auch neue Erwartungen – und nicht selten Unsicherheit. Gerade wenn eine Organisation alte Strukturen aufbricht, entstehen Freiräume, die zwar viel Potenzial bieten, aber auch überfordern können. Denn: Nur weil man offiziell mehr entscheiden darf, heißt das nicht, dass man automatisch auch die Sicherheit hat, diese Entscheidungen zu treffen. Vergangenes Verhalten, kulturelle Prägung und gewachsene Erwartungen wirken oft lange nach. Viele Product Owner:innen müssen sich erst wieder zutrauen, wirklich agil zu arbeiten – gerade wenn sie aus stark regulierten oder hierarchischen Kontexten kommen. Was hilft, ist nicht nur methodisches Know-how, sondern auch ein Bewusstsein für die eigenen Stärken. Wer weiß, wie er tickt, kann besser mit Unsicherheit umgehen. Tools wie der Gallup Strengths Finder oder persönliche Reflexionsformate (vgl. dazu auch Sei dein eigenes Produkt) können hier wertvolle Unterstützung sein. Doch Veränderung lässt sich nicht allein stemmen. Die Verantwortung als Product Owner:in entwickelt sich in einem Umfeld weiter – und dieses Umfeld muss mitziehen. Teams, Stakeholder, Führungskräfte: Alle sind Teil des Veränderungsprozesses. Das bedeutet nicht nur neue Absprachen und Verantwortlichkeiten, sondern auch das Aushalten von Reibung. Widerstände gehören dazu – und sie sind oft kein Zeichen von Ablehnung, sondern Ausdruck von Unsicherheit. Was es braucht, ist Kommunikation auf Augenhöhe und die Bereitschaft, sich gemeinsam auf Neues einzulassen. Veränderung gelingt nicht durch starre Frameworks oder das bloße Umbenennen von Rollen. Sie braucht Begleitung, Reflexion – und vor allem Zeit. Workshops, Coachings, Community-Formate oder interne Netzwerke können dabei helfen, einen stabilen Rahmen zu schaffen, in dem Entwicklung möglich ist. Der wichtigste Rat von Annette und Maik: Ruhe bewahren. Nicht jede Veränderung ist sofort greifbar – aber sie ist eine Chance. Für persönliches Wachstum, für bessere Produkte und für eine stärkere Verbindung zwischen Technik, Business und Kund:innen. Am Ende ist es keine Frage, ob sich die Rolle des Product Owners verändert. Die Frage ist, wie wir damit umgehen. Wer neugierig bleibt, reflektiert und bereit ist, dazuzulernen, kann aus dem Wandel einen echten Entwicklungsschub machen. Für sich selbst – und für das ganze Produktteam.
April 7, 2025
Eine Zertifizierung ist für viele Product Owner ein Thema, das immer wieder aufkommt – oft dann, wenn sie neu in der Rolle sind oder sich weiterentwickeln wollen. Doch was bringt eine Zertifizierung wirklich? Ist sie nur ein Türöffner für den ersten Job oder hilft sie tatsächlich dabei, ein besserer Product Owner zu werden? Gleichzeitig gibt es eine Vielzahl an Anbietern für solche Zertifizierungen – von etablierten Organisationen wie der Scrum Alliance oder scrum.org bis hin zu eher unbekannten Anbietern. Jede Organisation verspricht einen eigenen Mehrwert. Manche Zertifikate lassen sich durch das Bestehen eines Online-Tests erwerben, andere setzen auf Trainings mit erfahrenen Coaches. Doch nicht jede Zertifizierung passt zu jedem Kontext oder Lerntyp. Eine Zertifizierung kann ein guter Einstieg sein, um sich strukturiert mit den Grundlagen des Product Ownership auseinanderzusetzen. Sie gibt Orientierung und zeigt, welche Themen zur Rolle gehören. Aber sie ersetzt nicht die tägliche Praxis, nicht den Austausch im Team, nicht die Auseinandersetzung mit Stakeholdern oder Nutzerbedürfnissen. Wer Product Owner ist, lernt ständig dazu – unabhängig vom Zertifikat auf dem Papier. Besonders spannend wird es, wenn wir uns die Motivation anschauen, warum Menschen überhaupt eine Zertifizierung machen wollen. Geht es um ein besseres Gehalt? Um Sichtbarkeit im Unternehmen? Oder darum, sich selbst sicherer in der Rolle zu fühlen? Je nach Zielsetzung können ganz unterschiedliche Formate sinnvoll sein. Für manche ist zum Beispiel ein Einstiegskurs wie der „Professional Scrum Product Owner“ (PSPO I) ideal, andere profitieren mehr von Advanced-Kursen mit Fokus auf Stakeholder-Management, strategischer Produktentwicklung oder Leadership. Zertifizierungen sind also weder gut noch schlecht – sie sind Werkzeuge. Und wie bei allen Werkzeugen kommt es darauf an, wie man sie einsetzt. Ein Product Owner, der gelernt hat, wie wichtig kontinuierliche Validierung von Hypothesen ist, wird sich nicht auf ein Zertifikat verlassen, sondern im Alltag ausprobieren, verwerfen, neu denken. Genau das macht die Rolle so anspruchsvoll – und so spannend. Am Ende zählt weniger, welches Logo auf dem Zertifikat steht, sondern was die Person daraus macht. Wer bereit ist, kontinuierlich zu lernen, Feedback anzunehmen und sich mit anderen POs zu vernetzen, braucht nicht unbedingt eine Zertifizierung, um gute Arbeit zu leisten. Aber sie kann ein sinnvoller Baustein sein – vor allem dann, wenn sie nicht als Endpunkt, sondern als Anfang verstanden wird.
t3n Digital Pioneers
Isabel Grünewald, heise online
Joel Kaczmarek
Harvard Business manager
Alexander Graf & Karolin Junker De Neui
Philipp Westermeyer - OMR
Sebastian Matthes, Handelsblatt
Christoph Magnussen & Michael Trautmann
Wondery
c’t Magazin
Quarks
detektor.fm – Das Podcast-Radio
NDR Info
Jan Böhmermann & Olli Schulz
Larissa Holzki
Pod Engine is not affiliated with, endorsed by, or officially connected with any of the podcasts displayed on this platform. We operate independently as a podcast discovery and analytics service.
All podcast artwork, thumbnails, and content displayed on this page are the property of their respective owners and are protected by applicable copyright laws. This includes, but is not limited to, podcast cover art, episode artwork, show descriptions, episode titles, transcripts, audio snippets, and any other content originating from the podcast creators or their licensors.
We display this content under fair use principles and/or implied license for the purpose of podcast discovery, information, and commentary. We make no claim of ownership over any podcast content, artwork, or related materials shown on this platform. All trademarks, service marks, and trade names are the property of their respective owners.
While we strive to ensure all content usage is properly authorized, if you are a rights holder and believe your content is being used inappropriately or without proper authorization, please contact us immediately at [email protected] for prompt review and appropriate action, which may include content removal or proper attribution.
By accessing and using this platform, you acknowledge and agree to respect all applicable copyright laws and intellectual property rights of content owners. Any unauthorized reproduction, distribution, or commercial use of the content displayed on this platform is strictly prohibited.