Die Produktwerker

Christoph Steinlehner im Gespräch mit Tim Tim spricht in dieser Podcast-Folge mit Christoph Steinlehner, der mehrere Jahre in Washington, D.C. gelebt und gearbeitet hat. Mit seiner Erfahrung aus über 25 Jahren in Produktmanagement und Coaching bringt Christoph spannende Einblicke mit, wie Produktmanagement in den USA funktioniert – und was sich davon auf Europa übertragen lässt. Viele Produktmenschen schauen fasziniert ins Silicon Valley. Namen wie Amazon, Google oder Meta wirken wie Fixpunkte, an denen man sich orientiert. Christoph macht jedoch deutlich, dass dieses Bild nur einen kleinen Teil der Realität zeigt. Das Silicon Valley ist ein spezielles Ökosystem mit eigener Tradition, Netzwerken und Kapital. Doch außerhalb dieser Blase ist das Produktmanagement in den USA nach seiner Erfahrung oft erstaunlich nah an dem, was wir aus Deutschland kennen: Hierarchien, steife Strukturen und Unternehmen, die sich mit digitalen Transformationen schwertun. Spannend ist, wie unterschiedlich die Arbeitskultur für das Netzwerken und die Jobsuche ist. In großen Tech-Firmen haben Titel und Netzwerke einen hohen Stellenwert haben und so ist der Zugang zu anderen Produktmenschen in den USA oft leichter. Ein Intro über LinkedIn, ein Kaffee-Termin oder ein schneller Austausch sind gängige Wege, um ins Gespräch zu kommen. Für Christoph war dieses offene Netzwerken ein entscheidender Erfolgsfaktor in seinen drei Jahren vor Ort – und ein Unterschied, den er im deutschen Umfeld stärker verankert sehen möchte. Auch beim Thema Agilität zeigt sich ein anderes Bild als vielleicht vermutet. Zwar arbeiten viele Unternehmen in cross-funktionalen Teams, doch Frameworks wie Scrum sind nicht mehr so dominant wie noch vor einigen Jahren. Capital One zum Beispiel hat die Rolle des Scrum Masters abgeschafft. Während in Europa Scrum oft noch als Stütze genutzt wird, um agile Zusammenarbeit zu strukturieren, ist es in den USA vielerorts bereits im Rückzug. Stattdessen gewinnen andere Arbeitsweisen an Gewicht, die stärker auf Kultur, Eigenverantwortung und Outcome-Orientierung setzen. Christoph beobachtet zudem, dass Produktmanagement in den USA weniger vom Framework geprägt ist, sondern stärker durch Haltung und Praxis. Gerade in den großen Tech-Firmen braucht es nicht immer "offizielle" agile Prinzipien, weil die Kultur bereits auf Zusammenarbeit und Wissensaustausch ausgerichtet ist. Doch auch hier gilt: Es gibt nicht "das eine" Produktmanagement in den USA. Große Corporates kämpfen mit denselben Herausforderungen wie in Europa, während Startups eher mit Tempo und Experimenten punkten. Was bedeutet das für uns in Europa? Zum einen, dass wir uns nicht blenden lassen sollten von den Erfolgsbildern des Silicon Valley. Zum anderen, dass wir viel lernen können von der Offenheit, dem Mut zum Netzwerken und der klaren Ausrichtung auf Outcomes. Christoph selbst bringt aus seiner Zeit in den USA eine noch stärkere Fokussierung auf Visualisierung und Mapping-Methoden mit, die helfen, Diskussionen greifbarer zu machen und Teams in die Umsetzung zu bringen. Ein Punkt, der Tim als Story Mapping Experten und Fan von Assumption Mapping, Impact Mapping und der Arbeit mit einem Canvas sehr aus dem Herzen spricht. Christophs Erfahrung zeigt: Produktmanagement in den USA ist vielfältiger, bodenständiger und näher an unserer Realität, als viele annehmen. Wer mit offenen Augen hinschaut, entdeckt vor allem viele Möglichkeiten, das eigene Arbeiten mutiger und konsequenter zu gestalten. Im Gespräch wird auch diese Quellen und alte Podcast-Folge verwiesen: Das Product Operating Model von Marty Cagan - mit Sohrab Salimi Der Mapper Club von Christoph (in seinem Substack): https://mapper.club Never Search Alone: https://neversearchalone.org Joshua Seiden: Outcomes over Outcome Adam Grant: Geben und Nehmen Wer mit Christoph Steinlehner in den direkten Austausch kommen möchte, kontaktiert ihn am Besten über sein LinkedIn-Profil. Wie nimmst du die Unterschiede zwischen Europa und den USA im Produktmanagement wahr? Hast du schonmal ähnliche oder ganz andere Erfahrungen machen können? Teile deine Erfahrungen und Sichtweisen mit uns auf LinkedIn oder unter diesem Blogpost und lass uns gemeinsam diskutieren, welche Impulse wir für unsere Arbeit nutzen können um gemeinsam zu wachsen. Wir sind gespannt auf deine Erfahrungen, Perspektiven und Fragen. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Silke Kanes im Gespräch mit Oliver Mut ist im Produktalltag ein Thema, das oft unter der Oberfläche bleibt. Was braucht es, damit Product Ownerinnen und Product Owner nicht nur fachlich, sondern auch persönlich Verantwortung übernehmen? Oft sind es die Momente, in denen man spürt, dass etwas gesagt oder getan werden sollte, man sich jedoch zurücknimmt. Die Gründe dafür sind vielfältig und oft tief verankert. Darüber spricht Oliver mit Silke Kanes. Sie kennt diese Dynamik aus ihrer Arbeit als Coach und aus ihrer eigenen Produktlaufbahn. Für sie ist Mut kein angenehmes Extra, sondern eine grundlegende Voraussetzung, um in der Rolle wirksam zu sein. Wer Produktverantwortung trägt, muss Entscheidungen treffen, mit Unsicherheit umgehen, Klartext reden und Reibung aushalten. Dafür reicht Methodenwissen nicht aus. Es braucht Selbstreflexion, emotionale Stabilität und Klarheit über die eigene Rolle. Mut beginnt oft dort, wo die Komfortzone endet. Das kann der Moment sein, in dem es unbequem wird, in dem kein Applaus kommt oder man sich angreifbar macht. Genau in diesen Augenblicken entsteht Führung. Im Gespräch geht es auch um typische Spannungsfelder im Alltag von Product Ownern. Das passiert zum Beispiel, wenn Teams sich in Details verlieren, wenn Stakeholder drängen oder wenn die eigene Intuition signalisiert, dass etwas nicht passt. Wer in solchen Situationen stumm bleibt, ausweicht oder alles allein trägt, brennt langfristig aus. Mut zeigt sich häufig leise, etwa im klaren Nein zu einer weiteren Priorität, im offenen Gespräch über Zielkonflikte oder darin, Zweifel zu teilen, anstatt ein perfektes Bild zu wahren. Mut ist jedoch kein Einzelkampf. Silke beschreibt, wie sehr ein Umfeld mit psychologischer Sicherheit hilft. Ehrliches und unterstützendes Feedback, ein konstruktiver Umgang mit Konflikten und die Möglichkeit, sich weiterzuentwickeln, ohne sofort alles perfekt machen zu müssen, sind entscheidend. Oliver betont, dass Mut Raum braucht, um sichtbar zu werden. Dieser Raum kann in Retrospektiven, in Gesprächen auf Augenhöhe oder in Momenten entstehen, in denen jemand das Unausgesprochene anspricht. Auch Coaches und Führungskräfte brauchen Mut, um Themen offen anzusprechen, Strukturen zu hinterfragen und Product Ownern Rückendeckung zu geben. Am Ende ist Mut kein fester Wesenszug, sondern ein Muskel. Er wächst durch Übung, durch ehrliche Selbstreflexion und durch die Erfahrung, dass sich Bewegung lohnt. Wer in der Produktarbeit wirklich Verantwortung übernehmen will, kommt an dieser Arbeit nicht vorbei. Genau deshalb lohnt sie sich.

Tim & Oliver im Gespräch Product Backlog Management – von der Pflichtaufgabe zum strategischen Hebel Viele Product Owner sehen Product Backlog Management als lästige Pflicht. Dabei ist es laut Scrum Guide eine Kernaufgabe des Product Owners – und entscheidend für Klarheit, Wirksamkeit und Fokus. In dieser Folge sprechen Tim und Oliver darüber, warum viele Product Backlogs ausser Kontrolle geraten wie ein klares Product Goal Priorisierung und Stakeholder-Gespräche erleichtert, weshalb Kommunikation mehr ist als über Jira-Tickets sprechen und wie Mut zum Ausmisten den Weg zu mehr Fokus ebnet. Oliver teilt frische Erkenntnisse aus seiner Product Backlog Management Masterclass mit Product Ownern aus unterschiedlichen Branchen und zeigt, wie das Product Backlog vom Verwaltungstool zur strategischen Steuerungszentrale wird.

Tanja Heyken im Gespräch mit Dominique Tanja Heyken ist zu Gast bei Dominique, um gemeinsam auf das Thema „Designprinzipien“ zu schauen und was diese im Alltag von Produktteams tatsächlich bewirken können. Tanja bringt ihre doppelte Perspektive als UX-Professional und Product Owner mit, die sie bei Checkmk täglich lebt. Ihr Ziel ist es Entscheidungsprozesse zu vereinfachen, Konsistenz schaffen und die User Experience verbessern, ohne dafür jedes Mal von vorne zu diskutieren. Designprinzipien versteht sie dabei als konkrete, nutzerzentrierte Leitplanken. Sie helfen Teams, bessere Entscheidungen zu treffen – auch dann, wenn gerade niemand aus UX oder Product dabei ist. Die wichtige Grundlage dafür sind Daten: Wer mit Designprinzipien arbeiten möchte, sollte die Perspektive der Nutzer:innen ernst nehmen. Tanja empfiehlt den UEQ+ als kompaktes Instrument, um herauszufinden, welche Eigenschaften den Nutzenden wichtig sind und wie das Produkt aktuell wahrgenommen wird. Daraus lassen sich Designprinzipien ableiten, die zur Realität der Nutzer:innen passen, nicht nur zu den Annahmen im Team. Doch wie kommt man von ersten Erkenntnissen zu Prinzipien, die im Alltag wirklich nützlich sind? Für Tanja beginnt alles mit einem interdisziplinären Workshop. Entscheidend sind UX, Product, Entwicklung, Support, Sales; also möglichst viele Sichtweisen an einen Tisch holen, um gemeinsames Verständnis zu schaffen. Ziel ist nicht die perfekte Formulierung im ersten Anlauf, sondern die Entwicklung von sogenannten Proto-Prinzipien, die sich dann im Team schrittweise verfeinern und gegen reale Entscheidungen testen lassen. Dieser iterative Prozess sichert nicht nur Qualität, sondern stärkt auch die Akzeptanz im Unternehmen. Designprinzipien müssen einfach und greifbar sein. Drei bis fünf gut formulierte Prinzipien lassen sich besser merken und leben als zwölf ambitionierte. Spotify zeigt, wie es geht: Relevant, Human, Unified. Auch bei Figma sieht man, wie Eigenschaften wie „Thoughtful“ oder „Approachable“ Orientierung bieten können. Entscheidend ist aber nicht nur die Kürze, sondern das gemeinsame Verständnis dahinter: Was bedeutet z. B. „Human“ konkret im Produkt? Welche Sprache, welche Gestaltung, welche Entscheidungen zahlen darauf ein? Damit Designprinzipien im Alltag wirken, braucht es mehr als ein PDF oder einen Eintrag im Wiki. Prinzipien müssen kontinuierlich sichtbar gemacht werden, etwa durch Beispiele in Reviews, durch Argumentation im Daily oder durch Verankerung im Onboarding neuer Teammitglieder. Designprinzipien sind keine Regeln, sondern Orientierung. Sie ersetzen kein User Research, kein Testing, keine Interviews, aber sie geben Teams Sicherheit in Entscheidungen, die jeden Tag getroffen werden müssen. Die große Stärke von Designprinzipien liegt darin, dass sie helfen, auch in wachsenden Teams mit immer mehr Beteiligten eine konsistente UX sicherzustellen. Die Verknüpfung zu anderen Artefakten in der Produktentwicklung, etwa der Produktvision, dem Product Goal oder Sprintziel ist auch sehr spannend. Selbst wenn Designprinzipien keine direkten Bestandteile von Scrum sind, lassen sie sich gut als tägliche Entscheidungshilfe für alle, die das Produkt gestalten, in diese Strukturen einbetten. Wer Designprinzipien im Team etablieren möchte, sollte aber auch nicht zu perfektionistisch starten, sondern lieber loslegen, lernen und iterieren. Denn die besten Prinzipien entstehen nicht auf dem Papier, sondern in der echten Zusammenarbeit. Referenzen: Unter https://ueqplus.ueq-research.org/ gibt es mehr Infromationen zum UEQ+ Ein ähnliche sKonzept ist die UX Vision. Unter https://produktwerker.de/ux-vision/ findet ihr eine dazu passende Folge. Tanja steht euch natürlich für weitere Fragen zur Verfügung. Ihr erreicht si am besten unter https://www.linkedin.com/in/tanja-heyken-7a9406124/.

Oliver & Tim im Gespräch User Stories sind aus der agilen Produktentwicklung kaum wegzudenken, dennoch verursachen sie regelmäßig Reibung, Missverständnisse oder sogar echten Schaden im Entwicklungsprozess. In dieser Folge schauen sich Oliver und Tim die größten Fehler bei der Arbeit mit User Stories an und sprechen offen darüber, wie sie selbst immer wieder in diese Fallen getappt sind. Diese sind kurz formuliert: Wir schreiben User Stories Wir nehmen User Stories ab Wir definieren Lösungen Wir schneiden User Stories falsch Wir pressen alles ins User Story Format Unser Angebot: Online Masterclass Hier gibt's alle weiteren Infos: "Erfolgreich mit User Stories arbeiten" Ein häufiger Fehler beginnt schon beim Schreiben: Statt sich gemeinsam ein Bild vom Nutzerproblem zu machen, werden Storys im stillen Kämmerlein formuliert und (nur) in Schriftform ins Sprint Planning gebracht. Dabei soll die Story eher ein Erinnerungspunkt für ein Gespräch sein, nicht das Gespräch ersetzen. Die Diskussion über das zugrundeliegende Problem, also das gemeinsame Verstehen der Nutzerbedürfnisse – ist der Schlüssel. Storytelling und entwickeln von Problemempathie mit dem Team führen zu besseren Lösungen. Und genau dafür braucht es ein Gespräch, kein perfekt ausgefülltes Template oder "Ticket". Der nächste Trugschluss: User Stories müssten irgendwie "abgenommen" werden. Diese Idee stammt noch aus einer Projektlogik und widerspricht dem agilen Grundgedanken. Akzeptanzkriterien dienen nicht als Vertrag, sondern als Einladung zur gemeinsamen Einschätzung: Haben wir das gemeinsam verstandende Problem gut genug gelöst? Abnahme-Rituale im Sprint Review mit "Daumen hoch oder runter" führen hier meist in die Irre. Vielmehr geht es um Reflexion ob die gefundene Lösung zum Nutzerproblem passt – im besten Fall sogar mit Feedback der eigentlichen Nutzer:innen. Besonders schädlich wird es, wenn Product Owner anfangen, in User Stories ihre Lösungen dertailliert vorzugeben. Dann bleibt wenig Raum für Kreativität oder bessere Ideen aus dem Team. Eine gute User Story wird im Problemraum formuliert und darf dabei auch gerne eine LösungsIDEE mitbringen. Sie macht Wirkung und Ziel verständlich – nicht den genauen Umsetzungspfad. Wenn alles schon vorgegeben ist, gibt es keine echte Zusammenarbeit mehr. Auch beim Schneiden von User Stories wird viel Potenzial verschenkt. Zu große Storys, die sich über mehrere Sprints ziehen, nehmen uns die Chance für kurzfristiges Feedback und verlangsamen damit die Lernkurve. Und wenn denn geschnitten wird sorgen horizontale Schnitte entlang technischer Komponenten eher für Abhängigkeiten statt echten Mehrwert. Der Weg zu kleinen, vertikal geschnittenen Storys ist nicht immer leicht, aber entscheidend für schnelles Feedback bzgl. der erwünschten Wirkung (Outcome). Und dann wäre da noch das "Connextra"-Template. Es kann helfen, den Einstieg zu finden. Aber wer alles in das Format "Als (Nutzer) möchte ich…, damit …" zwängt, läuft Gefahr, das Denken zu verengen. Nicht jede Aufgabe ist eine User Story und nicht jede User Story braucht eine feste Form in diesem Template. Es braucht ein Gefühl für das Problem, nicht nur eine korrekt ausgefüllte Schablone. Der größte Fehler ist oft der Versuch, mit der falschen Haltung an User Stories heranzugehen. Wenn das Format über das Verständnis gestellt wird, wenn Gespräche durch Jira-Tickets ersetzt werden, wenn Stories zu Mikro-Aufträgen oder Fachfeinspezifikationen verkommen, geht der Sinn für die Arbeit mit User Stories verloren. User Stories sind ein Mittel zur Zusammenarbeit, kein bürokratischer Selbstzweck. Wer das versteht, nutzt sie, um gemeinsam zu denken, nicht nur um Aufgaben ans Team zu dokumentieren. In dieser Folge wurde auf eine ganze Reihe früherer Episoden verwiesen: Erfolgreich mit User Stories arbeiten Wer nimmt User Stories ab? User Story Splitting: Wie geht das "richtig"? Arten von Product-Backlog-Einträgen: Was gibt's neben User Stories noch? Akzeptanzkriterien richtig einsetzen Mit Storytelling andere von Deinen Produktideen überzeugen Welche Fehler bei der Arbeit mit User Stories beobachtest du in deinem Team bzw. hast sie überwunden? Was funktioniert bei euch gut – und was weniger? Wir sind gespannt auf deine Erfahrungen, Perspektiven und Fragen. Komm mit uns ins Gespräch und lass uns gemeinsam weiterdenken. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Oliver & Dominique im Gespräch Dominique spricht in dieser Folge mit Oliver darüber, was in dem vor einigen Wochen veröffentlichen Scrum Guide Expansion Pack für Product Owner steckt. Während der Scrum Guide seit 2020 nicht mehr aktualisiert wurde, liefert das Expansion Pack nun zusätzliche Erläuterungen, neue Rollen, erweiterte Verantwortlichkeiten und vertiefte Perspektiven auf Produktentwicklung mit Scrum. Was davon ist hilfreich? Was bringt neue Klarheit – und was vielleicht neue Verwirrung? Die Idee des Expansion Packs: Scrum verständlicher machen und anschlussfähiger an die Herausforderungen der Produktentwicklung in der Zukunft. Dabei setzen die Autoren rund um Jeff Sutherland, Ralf Jocham und John Coleman auf Ergänzungen statt grundlegende Veränderungen. Doch genau das macht es spannend – und auch anspruchsvoll. Denn viele der zusätzlichen Perspektiven, etwa zu Rollenverständnis, Stakeholder-Zusammenarbeit oder Discovery, gehen deutlich über das hinaus, was der ursprüngliche Scrum Guide als Framework abbildet. Für Product Owner enthält das Expansion Pack gleich mehrere konkrete "Erweiterungen". Discovery wird als fester Bestandteil von Scrum benannt – und sogar als Aufgabe des gesamten Scrum Teams. Das rückt die Realität vieler Teams näher an das, was ohnehin längst gelebt wird: Entscheidungen auf Basis echter Erkenntnisse und Daten statt reiner Feature-Wünsche. Product Owner werden dadurch hoffentlich weniger als reine Product Backlog Verwalter, sondern als Verantwortliche für den gesamten Produktlebenszyklus gesehen. Die Rolle wird explizit mit Produktmanagement-Kompetenz verbunden – inklusive strategischem Denken, Marktverständnis und Führungskraft auf Augenhöhe. Das war im Scrum Guide aus unserer Sicht auch immer so gemeint aber nicht explizit formuliert. Auch auf Artefakt-Ebene bringt das Scrum Guide Expansion Pack neue Impulse: Das klassische Produktinkrement wird ergänzt um das Produkt selbst als weiteres Artefakt, mit einem klaren Fokus auf Outcome. Gleichzeitig sorgt die Trennung von Output Done und Outcome Done für Irritationen – gerade, weil sie die Verantwortung zwischen Product Owner und Product Developer stärker aufteilt, als es aus unserer Sicht in der Praxis sinnvoll ist. Für Oliver und Dominique wird klar: Das ganze Team sollte an Outcome gemessen werden, nicht nur an fertigen Features. Neu definiert wird auch die Stakeholder-Rolle. Sie ist nicht länger nur eine diffuse Bezugsgruppe, sondern erhält im Expansion Pack eine klar beschriebene Verantwortung: aktiver Beitrag zum Erfolg des Produkts durch regelmäßige, zielgerichtete Interaktion mit dem gesamten Scrum Team. Diese Perspektive unterstreicht, wie stark gute Produktentwicklung auch von der Qualität der Zusammenarbeit mit dem Umfeld abhängt – und nicht nur vom internen Prozess. Ergänzt wird das durch eine weitere neue Rolle, den sogenannten Supporter. Gemeint sind meist Führungskräfte, die systemische Rahmenbedingungen schaffen, um Scrum-Teams handlungsfähig zu machen. Ob diese neue Begrifflichkeit wirklich nötig ist, bleibt offen – sie macht aber sichtbar, dass erfolgreiche Produktarbeit mehr braucht als nur ein gut laufendes Sprint Board. Neben der inhaltlichen Erweiterung bringt das Expansion Pack auch Risiken mit. Wo zusätzliche Begriffe und Rollen eingeführt werden, steigt die Komplexität – und damit die Gefahr, dass Organisationen beginnen, das Dokument als Blaupause zu verstehen. Dabei war Scrum immer als leichtgewichtiges Framework gedacht, das bewusst Interpretationsspielräume lässt. Dominique und Oliver plädieren dafür, das Expansion Pack als Impuls zu nutzen, nicht als Vorlage. Das gilt auch für die beschriebenen Einsatzmöglichkeiten von KI im Scrum-Kontext. Während das Expansion Pack versucht, auch hier Orientierung zu geben, bleibt offen, ob die konkreten Szenarien realistisch oder voreilig sind. Klar wird nur: Wer heute mit Scrum arbeitet, sollte sich damit auseinandersetzen, wie Technologie, Produktstrategie und Zusammenarbeit neu zusammenspielen – und welche Verantwortung daraus entsteht. Das Scrum Guide Expansion Pack bringt viele bekannte Diskussionen neu auf den Tisch. Es bietet Gelegenheit zur Reflexion, zum Weiterdenken und zum bewussten Entscheiden. Nicht jede Ergänzung wird in jedem Kontext sinnvoll sein. Aber wer Produktverantwortung ernst nimmt, findet hier gute Anlässe, den eigenen Standpunkt zu schärfen – und das eigene Verständnis von Product Ownership weiterzuentwickeln.

Sebastian Borggrewe im Gespräch mit Tim In dieser Folge spricht Sebastian Borggrewe mit Tim über den Wechsel vom Projektmodus zum Produktmodus – ein Schritt, den viele Organisationen gehen wollen, aber nicht konsequent schaffen. Es geht darum, wie Unternehmen aus der Logik individueller Aufträge, kurzfristiger Deadlines und kundenspezifischer Roadmaps herausfinden – und stattdessen lernen, kontinuierlich an einem echten Produkt zu arbeiten. Sebastian Borggrewe bringt dabei nicht nur Erfahrungen aus seiner Arbeit als CTO und Coach ein, sondern auch Impulse aus seinem neuen Buch "From Project Mode to Product Mode", das genau diesen Übergang praktisch greifbar macht. Im Projektmodus ist vieles planbar, aber wenig nachhaltig. Anforderungen werden von außen hereingetragen, Erfolg wird in Terminen gemessen, technische Komplexität wird ignoriert – solange das nächste Kundenfeature fertig wird. Doch je mehr Features ausgeliefert werden, desto instabiler wird das Produkt. Die Codequalität sinkt, die Produktverantwortung bleibt diffus, eine Product Discovery findet kaum statt. Organisationen reagieren, statt zu gestalten. Und genau hier beginnt der Unterschied zum Produktmodus. Im Produktmodus wird anders gedacht: es geht um Wirkung (Outcome) statt nur um Lieferung (Output) und um unsere Zielgruppen statt um Projektauftraggeber sowie um Roadmaps, die Hypothesen abbilden – statt um Auftragslisten. Diese Umstellung betrifft nicht nur Produkt und Entwicklung, sondern auch Sales, Marketing, Pricing und Führung. Denn solange das Angebot verspricht, alles für jeden bauen zu können, wird sich am Modus nichts ändern. Sebastian macht aber auch deutlich, wie wichtig es ist, diesen Wechsel nicht als reines Prozess- oder Methodenproblem zu sehen. Wer wirklich vom Projektmodus zum Produktmodus kommen will, muss systemisch denken. Rollen verändern sich, Verantwortlichkeiten müssen klarer werden, alte Glaubenssätze müssen hinterfragt werden. Der Weg ist selten geradlinig – aber notwendig, wenn Organisationen langfristig wirksame Produkte entwickeln wollen. Sebastian beschreibt typische Blockaden: Feature-Commitments aus dem Vertrieb, fehlende Segmentierung, Tech-Schulden durch Einzellösungen, Produktteams ohne echte Entscheidungsmacht. Und er zeigt, wie Veränderung in kleinen Schritten möglich wird. Indem Teams beginnen, Wirkung zu messen. Indem Discovery ernst genommen wird: indem Roadmaps nicht nur abbilden, was versprochen wurde – sondern was gelernt wurde. Wer sich aktuell fragt, warum die eigene Produktorganisation nicht vom Fleck kommt, obwohl alle anpacken: Diese Folge bietet Klarheit. Nicht als Lösung von außen, sondern als Einladung, die richtigen Fragen zu stellen – und eigene Antworten zu entwickeln. Wir empfehlen für eine tiefere Auseinandersetzung das neue Buch von Sebastian Borggrewe und Thomas Hartmann "From Project- to Product Mode - A Game Plan to Unlock Scalability for B2B Software Products" Genannte Quellen: Just Product Konferenz von Sebastian Borggrewe und Kollegen Product Masterclass Angebot Passende Folgen zu dieser Episode: Das Product Operating Model von Marty Cagan Wer mit Sebastian direkt in Kontakt treten möchte oder weitere Fragen an ihn hat, kontaktiert ihn am besten über sein LinkedIn Profil. Lebt ihr noch ein projektzentriertes Vorgehen oder habt ihr euch schon auf die Transformationsreise hin zum Product Model gemacht? 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. Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Dominique & Oliver im Gespräch Was zeichnet gute Conversational AI eigentlich aus? Welche Prinzipen bruacht es für eine gezielte Gestaltung? Genau darüber unterhalten sich Dominique und Oliver in dieser Folge und sie klären, wie sich digitale Produkte verändern, wenn Sprache zur primären Schnittstelle wird. Denn sobald wir uns mit Systemen unterhalten, entsteht etwas, das weit über Funktion hinausgeht: Beziehung. Und diese will gestaltet sein. Conversational AI ist nicht einfach ein neues Interface. Sie bringt eine neue Metapher in die Produktentwicklung. Früher waren digitale Produkte vor allem Werkzeuge – heute können sie zu Gesprächspartnern werden. Das verändert Erwartungen, Erleben und die Verantwortung in der Gestaltung. Wer mit Chatbots, Sprachassistenten oder GPT-Integrationen arbeitet, muss mehr tun, als ein paar gute Prompts schreiben. Es geht um Haltung, Verhalten und Beziehung. Doch dann stellt sich die Frage: Welche Rolle soll die Conversational AI im Produkt einnehmen? Ist sie ein einmaliger Helfer oder ein persönlicher Assistent? Entsteht eine flüchtige Begegnung oder eine langfristige Interaktion? Und wie spiegelt sich das in Sprache, Ton, Humor oder Autonomie wider? Dominique beschreibt, wie Werte und Prinzipien einer Organisation sich konkret in Conversational AI übersetzen lassen – über Tonalität, Reaktionen, Grenzen und Masterprompts. Auch allgemeine Designprinzipien verändern sich. Menschliche Kommunikation wird zur Vorlage für Interaktion. Systeme sollten Feedback aufnehmen, sich anpassen, aber auch ihre eigene Linie behalten. Sie dürfen Charakter haben, quirlig oder nüchtern, ernst oder verspielt. Aber immer konsistent – und im Einklang mit dem, was das Produkt ausmacht. Anthropomorphisierung ist kein Selbstzweck, sondern ein Werkzeug, um Interaktion greifbar zu machen. Wer mit Conversational AI arbeitet, gibt dem Produkt eine Stimme. Interesant ist dabei auch die Rückkopplung Mensch-Maschine, bei dem eine Conversational AI "lernt" was Nutzer:innen wollen/brauchen. Aber Lernen ist dabei nicht nur Sache der Maschine. Auch die Teams hinter dem Produkt müssen beobachten, reflektieren und nachschärfen. Denn Nutzer:innen geben Feedback – implizit, durch Nutzung, Sprache, Abbrüche oder Überraschung. Diese Rückmeldungen gilt es ernst zu nehmen. Wer sie ignoriert, verschenkt Entwicklungspotenzial. Gleichzeitig braucht es Verantwortung. Technisch ist vieles möglich – doch nicht alles sinnvoll. Dark Patterns funktionieren auch in Sprachinterfaces. Doch wer Beziehung aufbauen will, braucht Vertrauen. Und wer Vertrauen will, muss Haltung zeigen. Auch das ist Teil von Conversational AI: ethische Klarheit, bewusste Gestaltung, respektvoller Umgang. Am Ende bleibt festzuhalten, dass nicht jedes Produkt eine eigene Persönlichkeit oder ein Chatinterface braucht. Aber wer Conversational AI nutzt, sollte wissen, worauf er sich einlässt. Denn am Ende geht es um mehr als nur Funktion. Es geht darum, wie wir mit Technik umgehen – und wie Technik mit uns umgeht. Verlinkungen: Dominique verwies einmal auf die Folge mit dem Decision Stack. Dabei bezieht er sich auf die Abhängigkeit von Unternehmenswerten und den Werten, die das Produkt zum Ausdruck bringt. -> https://produktwerker.de/the-decision-stack/ Oliver hat noch auf die Folge der Sendung mit der Maus verwiesen, die in sehr einfacher Form vermittelt, was wir heutzutage unter KI verstehen. Auch für Erwachsene sehenswert. -> https://www.wdrmaus.de/extras/mausthemen/kuenstliche_intelligenz/index.php5

Sohrab Salimi im Gespräch mit Tim Die Weiterbildung als Product Owner ist mehr als das nächste Zertifikat im Lebenslauf. In dieser Podcastfolge sprechen Tim und Sohrab Salimi darüber, was gute Weiterbildung heute ausmacht – und warum viele Angebote an der Realität der Produktarbeit vorbeigehen. Sohrab bringt dabei nicht nur seine langjährige Erfahrung als Certified Scrum Trainer mit, sondern auch den Mut zur Veränderung: Nach zehn Jahren als zertifizierter Trainer bei der Scrum Alliance hat er sich entschieden, neue Wege zu gehen. Mit der Agile Academy hat er ein offenes Weiterbildungsmodell mitentwickelt, das praxisnäher, systemischer und flexibler ist als vieles, was es bisher gab. Im Gespräch geht es um den Unterschied zwischen theoretischem Lernen und anwendungsnahem bzw. erfahrungsbasiertem Lernen. Viele Product Owner haben ein Foundation-Training besucht – ob als CSPO, PSPO 1 oder Ähnliches. Doch was kommt danach? Genau da setzt anwendungsnahe Weiterbildung an: Lernen durch echte Beispiele, durch Austausch mit anderen Praktiker:innen, durch das Reflektieren eigener Herausforderungen. Sohrab schildert, wie wichtig es ist, dass Trainer:innen nicht nur Inhalte vermitteln, sondern auch Erfahrungen aus der eigenen Produktpraxis teilen können. Wer selbst Produktverantwortung erlebt hat, stellt andere Fragen – und gibt Antworten, die in der Realität Bestand haben. Gemeinsam mit einem Netzwerk aus erfahrenen Coaches, Trainer:innen und Praktiker:innen entwickelt Sohrab mit der (neuen) Agile Academy neue Lernpfade für Product Owner – von den Grundlagen bis hin zum anspruchsvollen Sparring auf Augenhöhe. Tim bringt die Perspektive der Produktwerker ein, die diesen Weg aktiv mitgehen werden – als Teil der Agile Academy, aber auch aus Überzeugung, dass Weiterbildung immer dann wirksam wird, wenn sie anschlussfähig an den Alltag ist. Mit Formaten, die sich an dem orientieren, was Produktmenschen wirklich brauchen: Austausch, Reflexion, Anwendung. Aus diesem Grund haben sich alle drei Produktwerker entschieden, als Botschafter (sog. "Agile Academy Amabassador" bei diesem neuen Weiterbildungsnetzwerk mitzuwirken. Oliver Winter wird sogar der Track Owner für den Lernpfad "Product Owner" werden. Er ist damit die zentrale Stelle, die über die Lernziele aller Product Owner Trainings der Agile Academy entscheidet. Dominique Winter übernimmt ebenfalls als Track Owner den Lernpfad "Agile UX". Die Produktwerker werden sich somit sehr prägend und mit viel Gestaltungswillen in dieses neue Weiterbildungskonstrukt einbringen. Ihr könnt davon ausgehen, dass man unsere Handschrift in diesen Tracks erkennen wird. Der Product Owner Track dürfte z.B. von einen guten Schwung Produktmanagement-Themen in den Lernzielen profitieren. Jeder neue Lernpfad ("Track") unterscheidet zwischen Verstehen (Understand), Anwenden (Apply) und Vermitteln (Teach). Das eröffnet neue Möglichkeiten – für erfahrene Product Owner, für Einsteiger:innen mit echtem Lernwillen und für Organisationen, die Weiterbildung nicht nur als Pflicht, sondern als Chance sehen. Zugleich ist das Modell offen für verschiedene Vorerfahrungen: Wer bisher über Scrum.org oder Scrum Alliance unterwegs war, kann problemlos in die weiterführenden Ausbildungsschritte einsteigen. Und wer sich lieber im eigenen Tempo weiterbildet, findet hochwertige Self-paced-Kurse mit klarer Struktur und echter Tiefe. Hier der versprochene Link zum deutschsprachigen Product Owner Online Course - diese Masterclass können wir uneingeschränkt empfehlen (beinhaltet 24 Stunden e-Learning für nur 249 €) Diese Episode ist ein ehrliches Gespräch über Qualität in der Product Owner Weiterbildung – und über den Anspruch, Produkte nicht nur zu entwickeln, sondern sich selbst dabei mitzuentwickeln. Wer mehr Wirkung entfalten will, braucht mehr als Methodenwissen. Es geht um Haltung, um Austausch – und um Formate, die beides fördern. Die bisherigen Episoden mit Sohrab Salimi: Das Product Operating Model von Marty Product Owner als Agile Leader Business- oder Nutzersicht: Welchen Blickwinkel sollte ein PO einnehmen? - mit Sohrab Salimi und Markus Andrezak Wer mit Sohrab Salimi direkt in Kontakt treten möchte, kontaktiert und folgt ihm am besten über sein LinkedIn-Profil. Weiterführende Infos zum neuen Zertifizierungsansatz der Agile Academy gibt es hier: https://www.agile-academy.com/de/service/introducing-certified-by-agile-academy/ Und unser Oliver Winter bietet auch bereits schon Zertifizierungstrainings an (Level 1 und auch Level 2, also der weiterführende Lernschritt, wenn Ihr die Foundation wie CSPO oder PSPO schon habt. Hier ist die Übersicht seiner Trainingstermine: https://produktwerker.de/agile-academy-trainings-oliver-winter. Welche Erfahrungen hast du mit der Weiterbildung als Product Owner bislang gemacht? Hast du bereits das eine oder andere Zertifikat erhalten? Wie praxisnah und relevant für Deine Produktverantwortung waren diese Zertifizierungsschritte? Was ist deine Meinung zum ganzen Thema? 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. Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Oliver & Tim im Gespräch Die fünf Scrum Werte stehen etwas unscheinbar im Scrum Guide – nur ein kurzer Absatz, gefühlt kaum mehr als eine Randnotiz. Und doch bilden sie die Grundlage dafür, dass iteratives Arbeiten, gemäß des Prinzips empirischer Prozesssteuerung, in Scrum überhaupt möglich ist. In dieser Folge sprechen Oliver und Tim darüber, wie Product Owner diese Scrum Werte im Alltag konkret leben können. Nicht abstrakt und theoretisch, sondern ganz praktisch – im Spannungsfeld von Verantwortung, Kommunikation und Produktführung. Viele Teams und Organisationen arbeiten mit Scrum, ohne die Bedeutung der Scrum Werte wirklich zu reflektieren. Dabei hängt vieles genau davon ab: Wie offen gehen wir mit Feedback um? Wie mutig sprechen wir Konflikte an? Wie sehr helfen uns Fokus, Commitment und Respekt dabei, Klarheit zu schaffen und wirkungsvoll zusammenzuarbeiten? Tim und Oliver nehmen sich alle fünf Scrum Werte vor – Commitment, Fokus, Mut, Offenheit und Respekt – und beleuchten sie aus der Sicht eines Product Owners. Sie zeigen, dass es nicht um perfekte Haltung oder moralische Überlegenheit geht – sondern um gelebte Verantwortung. Und um die Wirkung, die entsteht, wenn ein Product Owner diese Werte nicht nur benennt, sondern im täglichen Handeln sichtbar macht. Ob in der Priorisierung, im Stakeholder-Dialog oder im Sprint Review: Die Scrum Werte zeigen sich überall. Wer als Product Owner mutig ist, kann klare Entscheidungen treffen, statt es allen recht machen zu wollen. Wer respektvoll kommuniziert, schafft Vertrauen – gerade auch in schwierigen Situationen. Und wer offen bleibt, kann Feedback wirklich annehmen, ohne die eigene Position zu verlieren. Oft stehen diese Werte in Spannung zueinander – oder im Widerspruch zu dem, was das Umfeld verlangt. Hierzu hatten wir ja auch gerade die tolle Episode mit Johannes Schartau ("Strukturen, die Produktentwicklung behindern – und was ihr dagegen tun könnt"). Gerade unter Druck fällt es schwer, Respekt zu zeigen, mutig zu bleiben oder sich zu fokussieren. Und genau deshalb braucht es Reflexion. Ein klares Gespür dafür, welchen Wert ich in meinem Kontext gerade besonders stärken will. Und die Bereitschaft, kleine Schritte zu gehen, statt alles auf einmal verändern zu wollen. Diese Folge ist eine Einladung, den Scrum Werten mehr Raum zu geben – nicht als Theorie, sondern als Kompass im Alltag. Wer sie ernst nimmt, stärkt nicht nur die eigene Wirksamkeit als Product Owner, sondern auch das Vertrauen im Team und in die eigene Produktverantwortung. Folgende weiteren Episoden wurden im Gespräch genannt: Klarheit als Superpower für Produktmenschen Sei dein eigenes Produkt! – Weiterentwicklung für Product Owner Wie wirken die Scrum Werte in deinem Alltag als Product Owner? Welche erlebst du als besonders hilfreich – und wo wird es herausfordernd? Wir sind gespannt auf deine Erfahrungen, Perspektiven und Fragen. Komm mit uns ins Gespräch und lass uns gemeinsam weiterdenken. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Johannes Schartau im Gespräch mit Oliver Viele Product Owner:innen spüren es – aber können es oft nicht genau benennen: Irgendetwas in der Organisation steht der Produktarbeit im Weg. In dieser Folge spricht Oliver mit Johannes Schartau über genau solche Strukturen, die Produktentwicklung behindern und was man konkret tun kann, wenn man mittendrin steckt. Johannes bringt viel Erfahrung aus der agilen Organisationsentwicklung mit und zeigt, wie tief verwurzelte Muster in Unternehmen verhindern, dass Teams wirksam arbeiten können. Wenn Product Owner:innen formal die Verantwortung für ein Produkt tragen, aber faktisch keine Entscheidungen treffen dürfen, ist das kein individuelles Problem – sondern ein strukturelles. Viele Organisationen sind immer noch stark auf Vorhersagbarkeit, Projektplanung und Output optimiert. Dabei braucht erfolgreiche Produktentwicklung genau das Gegenteil: Spielräume, Feedbackschleifen und Entscheidungsfreiheit. Diese strukturellen Blockaden haben viele Gesichter. Budgetprozesse, die nur einmal im Jahr laufen. Matrixorganisationen, die Verantwortlichkeit aufteilen, bis nichts mehr übrig bleibt. Zentralisierte Funktionen wie UX oder Architektur, die nicht Teil der Teams sind. Oder Zielsysteme, die auf Umsatz und Liefertermine setzen – aber keine Verbindung zur tatsächlichen Wirkung im Markt haben. All das bremst die Produktentwicklung nicht nur aus, es entkoppelt Teams von dem, was eigentlich zählt: Nutzerverhalten, Marktveränderung, echte Wertschöpfung. Johannes und Oliver diskutieren, was Produktmenschen tun können, wenn sie sich in genau solchen Situationen wiederfinden. Sie zeigen, wie man den eigenen Handlungsspielraum erkennt, nutzt – und erweitert. Oft geht es dabei nicht um große Transformationen, sondern um kleine Schritte: klare Erwartungen klären, eigene Ziele greifbar machen, Verbündete finden, Hypothesen testen. Wer zum Beispiel aufzeigt, wie viel Zeit durch fehlende UX-Kapazität verloren geht, führt keine Ideologiedebatte – sondern eine einfache Kosten-Nutzen-Rechnung. Klar ist: Strukturen, die Produktentwicklung behindern, verschwinden nicht von allein. Doch sie lassen sich verändern, wenn Produktverantwortliche mit einem klaren Blick, systemischem Verständnis und viel Pragmatismus agieren. Es hilft, mit den bestehenden Regeln zu arbeiten, statt sich außerhalb davon zu stellen. Wer zeigt, welchen Wert eine kleine Veränderung bringt, wird gehört. Und wer konkrete Bitten formuliert – anstatt nur Frust zu teilen – bekommt eher Unterstützung. Diese Folge ist ein realistischer Blick auf das, was viele spüren, aber selten so offen benennen. Und sie macht Mut, Verantwortung zu übernehmen, ohne sich selbst zu überfordern. Denn Veränderung beginnt oft nicht mit einem neuen Organigramm – sondern mit einem gut gesetzten Gespräch.

Tim & Oliver im Gespräch In einigen Organisationen fehlt der Scrum Master – und oft übernimmt dann einfach die Product Ownerin oder der Product Owner diese Rolle gleich mit. Eine Doppelrolle, die auf den ersten Blick pragmatisch wirkt, aber in der Praxis große Risiken birgt. In dieser Folge sprechen Tim und Oliver offen darüber, was passiert, wenn die Verantwortung für Produkt und Team-Entwicklung in einer Person vereint ist – und warum das langfristig fast nie gut ausgeht. Viele Teams arbeiten ohne Scrum Master, weil die Rolle im Unternehmen noch nicht etabliert ist, keine passende Person gefunden wurde oder weil das Budget gekürzt wurde. Und es werden gefühlt immer mehr. Was dann oft folgt: Die Product Ownerin übernimmt einfach mit – lädt zu Events ein, moderiert Retrospektiven, erklärt Prozesse, arbeitet an der Team-Motivation. Klingt erstmal lösungsorientiert. Aber genau darin liegt das Problem. Eine funktionierende Produktentwicklung - vor allen in Scrum - lebt davon, dass Rollen klar getrennt sind. Die PO-Rolle fokussiert auf Wert, Wirkung, Nutzer:innen und Geschäftserfolg. Die Scrum Master-Verantwortlichkeit hingegen kümmert sich um Rahmenbedingungen, Prozessqualität und die Lern-Entwicklung des Teams. Wer beides gleichzeitig macht, verliert Fokus. Statt Marktchancen zu analysieren, steckt man in Moderation fest. Statt Stakeholder zu führen, erklärt man zum dritten Mal das Framework Scrum. Und am Ende leidet beides: das Produkt und das Team. Noch kritischer wird es, wenn in der Doppelrolle Interessenkonflikte auftreten. Wie soll eine Person gleichzeitig Coach sein und gleichzeitig Druck machen, weil ein Release ansteht? Wie kann man Konflikte moderieren, in denen man selbst Partei ist? Und wie wirkt das auf ein Team, das sich ohnehin fragt, ob es wirklich mitgestalten darf – oder doch nur Vorgaben bekommt? Gerade dort, wo Teams anfangen, echte Ownership zu übernehmen, blockiert die Doppelrolle oft ungewollt genau diesen Prozess. Das größte Risiko: Man gewöhnt sich daran. Alle tun so, als wäre das normal. Die Organisation spart sich eine Rolle, das Team freut sich über weniger Abstimmung, und die PO reibt sich auf. Diese Form der organisatorischen Schuld muss sichtbar gemacht werden. Es braucht Transparenz – und klare Absprachen, wie lange diese Übergangslösung trägt. Wer die Doppelrolle stillschweigend hinnimmt, macht es der Organisation zu leicht, nichts zu verändern. Die Folge zeigt, wie man trotz der Doppelrolle handlungsfähig bleibt – zumindest vorübergehend. Klare Rollensignale helfen. Externe Moderation entlastet. Reflektion im Team schafft Verständnis. Und vor allem: Man muss reden – mit dem Team, mit Vorgesetzten, mit anderen POs. Denn aus der Überforderung heraus entsteht keine gute Produktentwicklung. Wenn du selbst in der Doppelrolle steckst oder jemanden kennst, der dort gerade kämpft: Diese Folge hilft, die Situation klarer zu sehen – und erste Schritte raus aus dem Dilemma zu finden. Damit Verantwortung wieder dort landen kann, wo sie hingehört.

Olaf Bublitz im Gespräch mit Tim Wenn in Produktteams das Verständnis fehlt, reden Menschen oft aneinander vorbei. Und manchmal reichen ein Stift und ein Flipchart, um das zu ändern. Olaf Bublitz kennt diese Situationen gut. Als erfahrener Agilist, Berater und Mitautor des neuen Buchs Visual Product Ownership setzt er sich seit Jahren dafür ein, visuelle Methoden in der Produktentwicklung gezielter und wirkungsvoller einzusetzen. In dieser Folge spricht er mit Tim über die Kraft der Visualisierung. Nicht als Deko oder hübsches Extra, sondern als echte Unterstützung für Klarheit, Zusammenarbeit und Entscheidungsfindung. Denn visuelle Methoden in der Produktentwicklung helfen dabei, komplexe Zusammenhänge sichtbar zu machen – über alle Ebenen hinweg: von der Strategie bis zur operativen Umsetzung. Olaf versteht unter visuellen Methoden nicht nur Zeichnungen oder Sketchnotes. Für ihn beginnt visuelles Arbeiten schon mit einem Canvas, einem Taskboard oder einer Map. Sobald Informationen so aufbereitet sind, dass man sie auf einen Blick erfassen und besprechen kann, entsteht ein gemeinsamer Fokus. Und genau darum geht es in der Produktentwicklung: Orientierung schaffen und Diskussion ermöglichen – ohne sich in Textwüsten zu verlieren. Viele der Methoden, die Olaf beschreibt, helfen dabei, Perspektiven nebeneinander sichtbar zu machen. Ob Eventstorming, Story Mapping oder Strategy Maps: Sie bringen Teams ins Gespräch – und lassen Unterschiede, Lücken oder Missverständnisse frühzeitig erkennen. Genau das ist der eigentliche Mehrwert. Denn visuelle Methoden in der Produktentwicklung machen nicht nur Dinge sichtbar. Sie machen Zusammenarbeit möglich. Es geht nicht darum, möglichst viele Methoden zu nutzen, sondern diese passenden auszuwählen – je nach Kontext, Ziel und Team. In seinem Buch fasst Olaf über 50 bewährte Methoden zusammen und stellt sie in sogenannten Strings dar: sinnvolle Verbindungen von Methoden entlang typischer Fragestellungen in der Produktentwicklung. So entstehen keine isolierten Visualisierungen, sondern ein durchgängiger visueller Arbeitsraum. Besonders spannend wird es, wenn Teams ihre gesamte Produktarbeit sichtbar machen – etwa in Form eines sogenannten "Obeya"-Raums. Olaf beschreibt, wie visuelle Methoden in der Produktentwicklung dabei helfen, verschiedene Ebenen miteinander zu verbinden: Ziele, Kennzahlen, Roadmaps, Backlogs, Abhängigkeiten. Alles sichtbar, strukturiert und zugänglich – ob physisch im Raum oder digital auf einem Miro-Board. Was zählt, ist der gemeinsame Blick. Die Folge ist eine Einladung: Visualisierung nicht als Stilmittel zu sehen, sondern als praktisches Werkzeug. Wer damit beginnt, kleine Elemente sichtbar zu machen – ein Ablauf, eine Idee, ein Engpass – schafft einen Einstieg. Und wer als Produktteam konsequent mit visuellen Methoden arbeitet, verändert nicht nur die Art, wie Entscheidungen getroffen werden. Sondern auch die Qualität der Zusammenarbeit. Frühere Folgen die zum Thema gut passen bzw. in der Epsiode genannt wurden: Visual Leadership für Product Owner mit Sabina Lammert Klarheit als Superpower für Produktmenschen mit Arne Kittler Event Storming: Verständnis für komplexe Produkte schaffen mit Jürgen Meurer Nutze Story Mapping, um mit Stakeholdern über Outcome zu sprechen Wardley Mapping - Produktstrategie wie ein Schachspiel mit Florian Meyer Impact Mapping - was zahlt wirklich auf unser Business Ziel ein? mit Büşra Coşkuner Assumption Mapping Wer mit Olaf Bublitz in Kontakt treten möchte, erreicht ihn gut über sein LinkedIn-Profil. Die Website zum Buch findet ihr unter: visual-productownership.de. Welche visuellen Methoden nutzt ihr in der Produktentwicklung – und was funktioniert bei euch besonders gut? 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. Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Dominique & Tim im Gespräch Refinement ist kein Meeting. Es ist Produktarbeit. Aber wie viel Refinement braucht ein gutes Produktteam – und woran merkt man, ob es zu viel oder zu wenig ist? In der neuen Folge unseres Podcasts sprechen Dominique und Tim genau darüber. Das Product Backlog Refinement gehört zu den meist unterschätzten (kontinuierlichen) Aktivitäten im Alltag von Product Ownern. Für viele ist es ein Block im Kalender – ein weiteres Meeting, das Zeit kostet. Dabei wird oft übersehen, worum es wirklich geht: gemeinsam Klarheit schaffen. Denn das Missverständnis beginnt oft schon beim Begriff. „Refinement“ wird gerne als Scrum-Ritual verstanden. Als formaler Termin mit fixer Agenda. Doch darum geht es nicht. Es geht um kontinuierliche Verständigungsarbeit – um gemeinsames Denken und Entscheiden. Wenn das fehlt, entstehen Unsicherheiten. Kontextwechsel häufen sich. Sprints ziehen sich, Entscheidungen werden vertagt, statt getroffen. Was dann oft hilft sind weniger der Fokus auf das Meeting, als viel mehr der Fokus auf die Symptome: Bleibt die Energie in Schätzorgien hängen? Gibt es viele Rückfragen zur Umsetzung? Zieht sich die Abstimmung wie Kaugummi? Wenn sowas zu spüren ist, liegt es eher an der Qualität der gemeinsamen Produktarbeit. Ein wirksames Refinement schafft Kontext, bevor Missverständnisse entstehen. Es lebt nicht von starren Regeln, sondern vom Gespür fürs Team, Produkt und Umfeld: Wie viel Unsicherheit haben wir gerade? Wie selbstorganisiert sind wir unterwegs? Wie reif ist unsere Produktidee? Tim und Dominique machen in dieser Episode deutlich: Es braucht keine perfekte Vorbereitung. Sondern ein gutes Zusammenspiel aus Tiefe, Struktur und Offenheit. Mal früh im Sprint, mal spät. Mal im großen Kreis, mal mit nur zwei Beteiligten. Hauptsache: Es hilft dem Team, fundierte Entscheidungen zu treffen. Frühere Folgen zum Thema "Refinement": Product Backlog Refinement – Tipps für Product Owner Dein Backlog ist zu groß? Was tun? Wie gelingt bei euch ein gutes Refinement – und woran erkennt ihr, wenn es Zeit für Veränderung ist? Wie viel Refinement braucht dein Team – und was funktioniert bei euch besonders gut (oder gar nicht)? 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. Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Daniel Koppel im Gespräch mit OIiver In dieser Podcastfolge spricht Daniel Koppel mit Oliver über seinen Weg in die digitale Produktwelt – und darüber, wie ihn die Ausbildung zum Produktmanager beruflich und persönlich verändert. Daniel kommt nicht aus der IT. Er hat eine kaufmännische Ausbildung gemacht, im Lager gearbeitet, Verantwortung übernommen. Aber irgendwann merkt er: Das kann es nicht gewesen sein. Der Job funktioniert – aber erfüllt nicht. Und das soll sich ändern. Über Freunde aus der IT erfährt er mehr über agiles Arbeiten, über Quereinstiegsmöglichkeiten, über Produkte, die echten Nutzen bringen. Der Gedanke, sich beruflich neu auszurichten, wird konkreter. Daniel informiert sich, prüft Optionen und entscheidet sich schließlich für eine geförderte Ausbildung zum Produktmanager mit IHK-Abschluss. Nicht als Notlösung – sondern als echte Perspektive. In der Ausbildung lernt er, wie moderne Produktentwicklung funktioniert: von Design Thinking bis Scrum, von Customer Journey Mapping bis Roadmapping. Er absolviert Zertifizierungen zum Scrum Master und Product Owner, entwickelt Produktideen, arbeitet an echten Use Cases – und erlebt, wie viel Freude es macht, Produkte mitzugestalten statt nur zu verwalten. Gleichzeitig geht es um mehr als nur Inhalte. Daniel muss lernen, zu lernen. Sich zu strukturieren, dranzubleiben, Verantwortung zu übernehmen – auch für den eigenen Fortschritt. Genau das macht die Ausbildung zum Produktmanager für ihn so wertvoll: Sie fordert, aber sie gibt auch Sicherheit. Mit echtem Praxisbezug, sinnvollen Tools und guter Begleitung. Was ihm besonders hilft: Die Ausbildung wird durch einen Bildungsgutschein gefördert. Und sie gibt ihm die Möglichkeit, Schritt für Schritt in den Beruf hineinzuwachsen. Heute steht Daniel kurz vor dem Abschluss, bereitet sich auf Bewerbungsgespräche vor und merkt, wie gefragt die Themen sind, mit denen er sich beschäftigt hat. Agilität, Nutzerzentrierung, Produktstrategie – das, was vor einem Jahr noch Neuland war, gehört inzwischen zu seinem Werkzeugkasten. Daniels Geschichte zeigt, was eine gute Ausbildung zum Produktmanager leisten kann – besonders für Menschen, die den Quereinstieg wagen. Sie schafft Klarheit, stärkt Selbstvertrauen und eröffnet neue Wege. Und sie macht deutlich: Es ist nie zu spät, einen neuen Anlauf zu nehmen. Wenn du selbst mit dem Gedanken spielst, dich beruflich zu verändern, mehr Verantwortung zu übernehmen oder tiefer in die digitale Produktwelt einzusteigen – dann hör in diese Folge rein. Vielleicht ist es genau der Impuls, den du brauchst.

Dominique & Oliver im Gespräch Produktkrankheiten entstehen nicht über Nacht. Sie schleichen sich ein. Leise, manchmal kaum merklich. Und plötzlich ist das Produkt schwerfällig, das Team frustriert, die Nutzer:innen aus dem Blick geraten. In dieser Folge sprechen Dominique und Oliver über typische Produktkrankheiten, wie sie entstehen und was sie mit unserer täglichen Arbeit als Produktmenschen machen. Einige der Krankheiten wie „Featureitis“, „Tool-Tourette“ oder „Prozess-Sklerose“ kommen uns erschreckend bekannt vor. Es sind genau die Muster, die sich in vielen Organisationen festsetzen, obwohl eigentlich alle das Gegenteil wollen. Mehr Klarheit, mehr Wirkung, mehr Verantwortung. Featureitis bedeutet beispielsweise, dass ein Produkt mit jedem Sprint wächst, immer neue Features bekommt, aber niemand weiß mehr, wofür es eigentlich steht. Teams liefern zuverlässig, aber niemand prüft, ob es überhaupt jemandem hilft. Stakeholder:innen fordern Features, die niemand priorisiert – aber die trotzdem gebaut werden. Genau hier zeigen sich das Konzept einer Produktkrankheit in ihrer vollen Wirkung. Sie erzeugen Aktivität ohne echtes Ziel und sie lassen uns Routinen folgen, die sich irgendwann wie Wahrheit anfühlen. Typische Produktkrankheiten haben viele Ursachen. Sie entstehen durch Unsicherheit, durch fehlende Nutzerperspektive oder durch Organisationsstrukturen, die eher auf Output als auf Outcome optimiert sind. Manchmal ist es auch das Fehlen einer klaren Produktvision – oder zu viele Meinungen, die lauter sind als echte Erkenntnisse. Doch gerade weil Produktkrankheiten so verbreitet sind, lohnt es sich, sie beim Namen zu nennen. Nicht als Diagnose von außen, sondern als Einladung zur Reflexion, denn die erste wirksame Therapie ist Aufmerksamkeit: zu erkennen, dass etwas nicht stimmt. Und dann gemeinsam hinzusehen, was sich ändern lässt. Diese Podcastfolge ist keine Checkliste für die perfekte Produktentwicklung. Aber sie soll helfen, ein Vokabular für das zu entwickeln, was in vielen Teams spürbar ist aber selten offen angesprochen wird. Und die Folge soll Mut machen wieder öfter zu fragen: Lösen wir mit unserem Produkt wirklich ein relevantes Problem oder folgen wir gerade einer gut geölten Routine, die zwar funktioniert, aber niemandem hilft?

Arne Kittler im Gespräch mit Tim Klarheit ist für uns Produktmenschen ein entscheidender Faktor, um auch in unsicheren Situationen handlungsfähig zu bleiben. In unserer neuen Podcastfolge spricht Tim mit Arne Kittler – einem erfahrenem Product Leader, langjährigem CPO und Mitgründer der "Product at Heart"-Konferenz – darüber, warum Klarheit nicht bedeutet, alles zu wissen, sondern ein gemeinsames Verständnis zu schaffen, auf dessen Basis Teams ins Handeln kommen. Gerade in der Produktentwicklung arbeiten wir oft mit unvollständigen Informationen. Arne beschreibt Klarheit als bewusste Entscheidung: den Kontext so gut wie möglich zu erfassen und daraus hilfreiche Orientierung abzuleiten – auch wenn absolute Sicherheit nie erreichbar ist. Zusammenarbeit funktioniert nur, wenn wir bereit sind, Unklarheiten aktiv zu klären und gemeinsam tragfähige Annahmen zu entwickeln. Klarheit entsteht nicht von selbst. Sie muss immer wieder neu geschaffen werden, weil sich Rahmenbedingungen verändern. Wer das ignoriert, riskiert, auf überholten Annahmen zu entscheiden – mit allen Konsequenzen. Teams, die regelmäßig bewusst für Klarheit sorgen, arbeiten schneller, wirksamer und mit weniger Reibungsverlusten. Dabei ist Klarheit oft unbequem. Sie verlangt, innezuhalten, nachzufragen und auch unangenehme Themen anzusprechen. Es kostet Mut und Energie, in Meetings Unsicherheiten offen zu machen, statt einfach weiterzugehen. Doch genau das zahlt sich aus: Was am Anfang Zeit kostet, spart später doppelte Arbeit und verhindert Missverständnisse. Klarheit braucht eine Kultur, in der Fragen ausdrücklich erwünscht sind und Unsicherheiten nicht als Schwäche gelten. Psychological Safety wird so zur Basis für echte Zusammenarbeit. Nur wenn Menschen sich sicher fühlen, auch unbequeme Wahrheiten auszusprechen, können Teams wirkliche Klarheit herstellen und aufrechterhalten. Im Gespräch wird auch deutlich, wie stark bewusste Sprache zur Klarheit beiträgt: Nicht vage bleiben, sondern präzise formulieren, nachfragen, visualisieren – so entsteht aus einem "Wir haben uns doch verstanden" eine belastbare Grundlage für Entscheidungen. Klarheit hilft, den Nebel frühzeitig zu lichten, bevor aus kleinen Missverständnissen große Probleme werden. Arne bringt es treffend auf den Punkt: Produktmenschen tragen die Verantwortung, Klarheit herzustellen – selbst wenn es unbequem wird. Gerade in cross-funktionalen Teams und in der Zusammenarbeit mit Stakeholdern macht das den entscheidenden Unterschied zwischen gut gemeinter Abstimmung und echter Wirksamkeit. Wer Klarheit über Komfort (siehe auch Matthew LeMay) stellt, schafft die Basis für nachhaltige Produktentwicklung – und stärkt nicht nur das eigene Team, sondern auch die eigene Wirksamkeit als Product Owner oder Produktmanager:in. Weitere Empfehlungen zum Vertiefen In dieser Podcastfolge sprechen wir auch über Themen, die wir in früheren Episoden vertieft haben. Wenn ihr tiefer eintauchen wollt, empfehlen wir euch diese Folgen: POEM – Das Product Ownership Evolution Model The Decision Stack – bessere Entscheidungen treffen Ein Produkt einstellen – der Ramp Down von XING Events (mit Thomas Gläser) Starke Produktmanager entwickeln (mit Petra Wille) Weitere Quellen zu Klarheit Wir möchten euch insbesondere das neue Buch von Matt LeMay und die ebenfalls erwähnten Blog-Artikel von Arne Kittler zu den einzelnen Dimensionen von Klarheit empfehlen: Matt LeMay: Impact-first Product Teams Directional Clarity – Klarheit über die übergeordnete Richtung und Vision Situational Clarity – Klarheit über die aktuelle Situation und den nächsten sinnvollen Schritt Role Clarity – Klarheit über Rollen, Verantwortlichkeiten und Erwartungen im Team Clear Communication – klare, präzise und offene Kommunikation als Grundlage für Zusammenarbeit Clarity for Product Leaders – besondere Bedeutung von Klarheit in der Führungsverantwortung für Produktmenschen Wer mit Arne Kittler direkt in Kontakt treten möchte, erreicht ihn über seine Website (arnekittler.de) oder sein LinkedIn-Profil. Folgt ihm auch gerne auf LinkedIn. Konferenz Product at Heart in Hamburg Unsere klare Konferenzempfehlung ist die jedes Jahr von Arne organisierte Product at Heart in Hamburg - diesmal am Fr, 27. Juni 2025. Die Workshops am Vortag sind mal wieder schon komplett ausgebucht, aber für die Konferenz am Freitag gibt es derzeit noch letzte Tickets. Die Talks sind alle auf englisch und das Publikum (ca 700-750 Menschen) ist auch international (wenn auch im Schwerpunkt aus der deutschen Produktmanagement Szene). Diese von Petra Wille und Arne Kittler seit 2017 organisierte Veranstaltung (früher unter dem Namen "MTPengage") hat eine enorme Strahlkraft und bietet ganz hervorragend ausgewählte Speakerinnen und Speaker (dieses Jahr u.a. mit Marty Cagan, Henrik Kniberg) in einer großartigen Atmosphäre. Unser Tipp: plant in jedem Fall auch am Freitagabend noch die "After-Conference-Party" mit ein und reist erst am Samstag zurück - denn das ist ein großes Networking & Party Event! Was denkst du zum Thema Klarheit? Hast du schon mal so über dieses Thema und die unterschiedlichen Dimensionen nachgedacht? 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. Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Oliver & Tim im Gespräch 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: Product Thinking (Jeff Patton): The Mindset That Kills Product Thinking 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 (mit 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. Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Annette Greil & Maik Seyfert im Gespräch mit Dominique 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.

Dominique & Oliver im Gespräch 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.