Die Produktwerker

Viele Produktteams sind ständig beschäftigt – aber nicht immer wirksam. In dieser Episode spricht Oliver Winter mit Produktcoach Tim Herbig über echte Fortschritte in der Produktentwicklung. Ausgehend von seinem Buch „Real Progress“ teilt Tim, wie Teams durch klare Produktstrategie, bewusste Entscheidungen und lernorientiertes Arbeiten echten Impact schaffen. Statt sich in Methoden zu verlieren, gilt es, Verbindungen zu schaffen – zwischen Product Discovery, Product Delivery und Produkt Strategie. Eine Folge für alle, die sich weniger Output, aber mehr Outcome und Impact wünschen.

Viele Product Owner kennen das: Anforderungen sind sauber dokumentiert, die User Stories vollständig, Akzeptanzkriterien klar – und trotzdem entsteht am Ende etwas anderes als gedacht. In dieser Folge sprechen Tim und Oliver darüber, woran das liegt – und wie es besser geht. Sie zeigen, warum die Wirksamkeit von Anforderungen nicht vom Template abhängt, sondern von Sprache, Haltung und Kontext. Was heißt es, Anforderungen nicht nur zu schreiben, sondern gemeinsam zu denken? Wann wirkt eine Formulierung einladend – und wann einschränkend? Und wie gelingt echte Verständigung mit Stakeholdern und Teams? Eine Folge für alle, die ihre Kommunikation als Product Owner bewusst gestalten und so echte Wirkung erzielen wollen.

In dieser Podcastfolge spricht Tim mit Björn Schotte, Mitgründer und Geschäftsführer von Mayflower, darüber, wie tiefgreifend der Einfluss von AI auf Produktentwicklung bereits ist – und wie sich die Arbeit von Product Ownern, Entwicklerinnen und Organisationen verändert. Björn bringt dabei nicht nur seine Erfahrungen aus der agilen Softwareentwicklung ein, sondern zeigt, wie AI und Context Engineering die Produktarbeit grundlegend neu definieren. AI verändert nicht einfach nur Prozesse. Sie verschiebt den Fokus. Wo früher monatelange Diskussionen über Features und Architekturen nötig waren, entstehen heute funktionsfähige Prototypen in wenigen Stunden. Systeme, die sich selbst kontextbezogen steuern, liefern Vorschläge, testen Varianten und verbessern kontinuierlich die Ergebnisse. Damit rückt die eigentliche Frage in den Mittelpunkt: Wie kann man als Produktmensch diese Geschwindigkeit und künstliche Intelligenz sinnvoll nutzen, um echten Mehrwert für Nutzerinnen und Nutzer zu schaffen? Björn beschreibt aufgrund seiner Erfahrung, dass AI längst über das reine „Vibe Coding“ hinausgeht. Die Zukunft liegt für ihn im Context Engineering – also darin, KI-Systemen Zugang auch zu relevanten Unternehmensdaten, Prozessen und Werkzeugen zu ermöglichen. So können sie nicht nur auf Zuruf Code generieren, sondern eigenständig sinnvolle Entscheidungen im Entwicklungsprozess treffen. Diese agentischen Systeme lernen aus Daten, messen Auswirkungen und schlagen eigenständig Verbesserungen vor. Damit entsteht ein Kreislauf, in dem Produktentwicklung zu einem lernenden, sich selbst optimierenden Prozess wird. Für Product Owner bedeutet das eine Veränderung ihrer Rolle. Nicht mehr jede Entscheidung wird im Expertengremium getroffen. Stattdessen verlagert sich Verantwortung dahin, wo Arbeit tatsächlich passiert – in die Teams und an die Schnittstelle zwischen Mensch und Maschine. Die Aufgabe verändert sich: vom Entscheider hin zum Orchestrator. Jemand, der den Rahmen schafft, in dem Menschen, Daten und AI-Systeme gemeinsam wirken können. Ein Beispiel: Mayflower entwickelt Voice-AI-Lösungen, die in Echtzeit mit Menschen sprechen, lernen und kontextbezogen reagieren. Damit verschwimmen die Grenzen zwischen Development, AI und User Experience. Produktentwicklung wird zu einem Dialog – zwischen Mensch, Maschine und Nutzer. Auch in der Modernisierung von Legacy-Systemen zeigt sich der Einfluss von AI: Software kann heute automatisch dokumentiert, getestet und migriert werden. Entwicklerinnen werden nicht ersetzt, sondern durch AI aufgeladen – schneller, präziser und mit deutlich höherer Testabdeckung. Doch die größte Herausforderung liegt nicht in der Technologie, sondern in der Organisation. Klassische Hierarchien und lange Entscheidungswege bremsen aus. Wer den Einfluss von AI auf Produktentwicklung wirklich nutzen will, muss Strukturen verändern – Budgetierung, (Entscheidungs-)Verantwortlichkeiten, Zusammenarbeit. Entscheidungen gehören dahin, wo die Arbeit geschieht. Dorthin, wo AI, Daten und Menschen gemeinsam im Produktentwicklungsprozess lernen. Am Ende dieser Entwicklung steht kein Kontrollverlust, sondern eine neue Form moderner Produktentwicklung. Eine, die Geschwindigkeit mit Lernfähigkeit verbindet. Für Product Owner heißt das: Jetzt ist die Zeit, sich mit AI auseinanderzusetzen – nicht theoretisch, sondern praktisch. Wer versteht, wie AI die Arbeit erleichtert, kann schneller handeln, bessere Produkte bauen und mehr Wirkung erzielen. Das Gespräch knüpft wunderbar an unsere vorletzte Podcast-Folge mit Ben Sufiani "Ist Vibe Coding relevant für die Produktentwicklung?" an. Wer weitere Fragen an Björn Schotte hat oder mit ihm ins Gespräch kommen möchte, erreicht ihn am Besten über ein LinkedIn-Profil oder per Mail (bjoern.schotte@mayflower.de. Wie verändert AI deinen Arbeitsalltag in der Produktentwicklung? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst.

Ist Scrum-Wissen als Product Owner eigentlich notwendig, um die eigene Rolle gut auszufüllen? Tim und Oliver erleben in ihrer Arbeit, dass hier oft Unsicherheit herrscht. Manche POs fühlen sich unter Druck, jedes Detail auswendig kennen zu müssen, andere verlassen sich stark auf Scrum Master oder Teams und verlieren dabei das Verständnis für die Grundlagen. Und gilt das auch, wenn ich mit meinem Team gar kein Scrum mache? Klar ist, dass Product Owner die Verantwortung für den Produkterfolg tragen. Dafür braucht es nicht nur ein Gespür für Markt, Kunden und Strategie, sondern auch ein solides Fundament im Scrum-Framework. Wer nicht weiß, wie Artefakte, Events und Verantwortlichkeiten ineinandergreifen, kann kaum sicherstellen, dass das Team wirkungsvoll zusammenarbeitet. Gleichzeitig reicht reines Regelwissen nicht aus. Ein Product Owner muss die Prinzipien verstehen, um sie im Alltag an den richtigen Stellen anzuwenden. Scrum-Wissen ist dabei kein Selbstzweck. Es geht nicht darum, im Scrum Guide jede Passage zitieren zu können, sondern um ein Verständnis dafür, wie das Framework Teams unterstützt. Eine Product Ownerin, die versteht, warum das Sprintziel Orientierung gibt, warum ein Backlog nicht nur eine Liste, sondern ein Instrument der Fokussierung ist, und wie das Inkrement Vertrauen bei Stakeholdern schafft, wird wirkungsvoller arbeiten können. Oliver und Tim betonen, dass Product Owner nicht alles alleine schultern müssen. Scrum ist ein Team-Framework, und die Verantwortung verteilt sich bewusst. Doch ohne eigenes Scrum-Wissen droht die Gefahr, die Rolle zu stark auf Stakeholder-Management oder Roadmaps zu verengen. Wer dagegen die Regeln und Prinzipien kennt, kann selbstbewusst auftreten, die Zusammenarbeit mit dem Scrum Master gestalten und dem Team eine klare Richtung geben. Ein weiterer Aspekt ist die Weiterentwicklung. Scrum-Wissen ist nichts Statisches, das man einmal lernt und dann abhakt. Mit jeder Retrospektive, jeder Review und jedem Refinement wächst die Erfahrung, wie die Prinzipien in der eigenen Organisation wirken. Gerade in komplexen Umfeldern braucht es die Bereitschaft, immer wieder Neues auszuprobieren und das eigene Verständnis von Scrum zu hinterfragen. Am Ende geht es nicht darum, als Product Owner ein wandelndes Scrum-Lexikon zu sein. Entscheidend ist, die Grundlagen so zu verinnerlichen, dass sie Orientierung geben, ohne dogmatisch zu wirken. Wer Scrum-Wissen klug einsetzt, schafft Klarheit im Team, fördert Verantwortung und sorgt dafür, dass das Framework seinen eigentlichen Zweck erfüllt: den Raum für wirksame Produktentwicklung. In der Diskussion wird auf den kostenfreien Scrum Foundations Online-Kurs der Agile Academy verwiesen. Ähnliches gibts auch als Agile Fundamentals Online-Kurs. Wir können hier aber auch explizit den ausführlichen Product Owner Online-Kurs mit satten 20 Stunden Videomaterial und Übungen empfehlen. Wir im Podcast erwähnt, bieten wir nun aber auch als Produktwerker selber Zertifizierungstrainings (vor Ort in Köln) an. Oliver Winter ist hierbei unser Trainer. Neben dem Training "Product Owner Level 1" gibt es auch das spannende "Product Owner Level 2" Training als wertvolle Weiterführung für alle, die schon PSPO I (von Scrum.org) oder CSPO (von der Scrum Alliance) und weitere Erfahrung als Product Owner. Beide Trainings bietet Oliver b.a.W. jeweils einmal im Quartal an - und wie erwähnt gibt es im Anschluss die Zertifizierung der Agile Academy. Warum wir nun auch zertifizierte Trainings anbieten, erklärt sich durch diese recht aktuelle Podcast-Folge Anwendungsnahe Weiterbildung - für mehr Erfolg als Product Owner". Diese älteren Episoden werden im Gespräch erwähnt: - Scrum Product Owner vs. SAFe Product Owner - ein Missverständnis - Kennt Kanban Product Owner? - Product Owner ohne Scrum Master - geht das? Wie viel Scrum-Wissen hältst du für notwendig, um als Product Owner erfolgreich zu sein? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns teilst.

In dieser Podcastfolge spricht Tim mit Ben Sufiani über ein Thema, das derzeit viel Aufmerksamkeit erfährt: Vibe Coding. Ben Sufiani, Gründer von Pirate Skills bringt nicht nur seine Erfahrung aus Growth Marketing, Produktentwicklung und Entrepreneurship ein, sondern auch seine Begeisterung für die Möglichkeiten, die entstehen, wenn AI das Schreiben von Code unterstützt. Im Gespräch geht es darum, wie Vibe Coding funktioniert, welche Chancen es für Produktmenschen eröffnet und welche Rolle Entwicklerinnen und Entwickler in diesem Wandel spielen. Ben beschreibt Vibe Coding als nächsten Schritt in der Entwicklung digitaler Produkte. Statt jede Zeile Code selbst zu schreiben, nutzen Teams KI-gestützte Tools, um schneller Prototypen, aber auch funktionsfähige Anwendungen zu erstellen. Für Entwickler bedeutet das einen enormen Produktivitätsschub, während Produktmanager und Product Owner erstmals selbst die Möglichkeit haben, Ideen in funktionierende Software zu verwandeln, ohne tief in die Programmiersprachen einsteigen zu müssen. Dadurch verschiebt sich der Fokus stärker auf das Verständnis der Nutzerbedürfnisse bzw. des zu lösenden Problems und die Qualität der Lösung. Tim und Ben diskutieren auch die kulturellen Spannungen, die entstehen können. Manche Entwickler fürchten den Verlust von Kontrolle und Qualität, andere sehen die neuen Möglichkeiten als unverzichtbar an. Klar wird, dass Vibe Coding mehr ist als ein kurzfristiger Trend. Es verändert die Zusammenarbeit zwischen Produktmenschen und Tech-Teams, indem es neue Formen gemeinsamer Kreativität eröffnet. Wenn Produktmanager direkt mit AI-gestützten Tools Prototypen bauen, wird die Brücke zwischen Discovery und Delivery kürzer und die Geschwindigkeit, in der Produkte getestet und weiterentwickelt werden, nimmt deutlich zu. Ben erzählt zudem von seinen eigenen Erfahrungen, von ersten Experimenten bis hin zu funktionierenden SaaS-Anwendungen, die er in Rekordzeit entwickeln konnte. Dabei wird deutlich, dass Vibe Coding kein Ersatz für professionelle Softwareentwicklung ist, sondern ein Beschleuniger für Ideen und ein Werkzeug, um schneller ins Gespräch mit Nutzern zu kommen. Gerade Produktmenschen profitieren davon, weil sie lernen, ihre Konzepte unmittelbarer zu erproben und ihre Teams so mit greifbaren Ansätzen zu inspirieren. Ein weiterer spannender Punkt im Gespräch ist die Frage nach den Grenzen: Welche Anwendungen lassen sich mit Vibe Coding sinnvoll umsetzen? Wie steht es um Sicherheit, Datenhoheit und die Zukunftsfähigkeit des generierten Codes? Ben erklärt, dass Vibe Coding zwar vieles einfacher macht, aber nicht jede Herausforderung löst. Umso wichtiger ist es, die Technologie bewusst einzusetzen, Verantwortung zu übernehmen und die eigenen Kompetenzen als Produktmensch gezielt einzubringen. Gerade jetzt steht ein Fenster offen, in dem Produktmanager, Product Owner und Teams enorm profitieren können. Wer Vibe Coding ausprobiert, entwickelt nicht nur neue Skills, sondern auch ein besseres Verständnis für die Arbeit der Entwickler und die Geschwindigkeit, mit der Produkte entstehen können. Als Start und zum Ausprobieren empfiehlt Ben Sufiani mit dem Tool https://v0.app/ zu starten. Mehr über Ben Sufiani erfahrt ihr unter Pirate Skills oder kontaktiert ihn gerne auch bei weiteren Fragen über sein LinkedIn-Profil. Wer sich tiefer in das Thema Vibe Coding einarbeiten möchte, dem empfehlen wir den Einstieg über Bens Schritt-für-Schritt Anleitung "Vibe Coding Codex" - zu finden auf seiner o.g. Website: pirateskills.com/vibecoding/codex. Für den richtigen Boost bietet sich ansonsten das im Gespräch kurz beschriebene 6-Wochen Programm "From Zero to SaaS" an. Es startet zu Beginn jeden Quartals. Jetzt kurzfristig als ab 1.Oktober 2025. Mehr Infos dazu hier: pirateskills.com/vibecoding/saas-in-6-weeks. Und denkt dran: Ben gibt für die Hörerinnen und Hörer dieses Podcasts mit dem Code "DPW250" einen satten 25%-Rabatt im Wert von 250€.

In dieser Folge berichtet Thomas Jackstädt, der Präsident der German UPA, über die aktuelle Entwicklung des Berufsbilds von UX-Professionals, als Menschen, die Produkte und Services so gestalten, dass sie nutzbar, verständlich und erlebbar werden. Doch das Bild dieser Rolle ist in Bewegung. Unterschiedliche Titel wie UX-Designer, Service-Designer oder Strategic Designer machen es Teams schwer, den Mehrwert von UX-Professionals eindeutig zu greifen. Thomas erklärt, dass die German UPA als Berufsverband für UX-Professionals daran arbeitet, Orientierung zu schaffen und das Berufsbild klarer zu definieren. Dabei geht es nicht um starre Festlegungen, sondern um Empfehlungen, die sowohl UX-Professionals selbst als auch Unternehmen, Hochschulen und Weiterbildungsanbieter nutzen können. Klarheit ist für die Zusammenarbeit im Team, für Recruiting und für die Ausgestaltung von Rollenprofilen entscheidend. Ein (wenig überraschender) Treiber dieser Veränderungen ist die künstliche Intelligenz. Während die Digitalisierung Informationen schnell verfügbar gemacht hat, verändert KI die Art, wie Inhalte und Designs überhaupt entstehen. UX-Professionals müssen lernen, diese Werkzeuge sinnvoll einzusetzen, ihre Qualität einzuschätzen und zu orchestrieren. So können sie den Freiraum nutzen, sich stärker auf die menschliche Erfahrung im Nutzungskontext zu konzentrieren. Gleichzeitig bleibt die Unterscheidung zwischen Professionalität und Amateurarbeit wichtig. Professionalität bedeutet nicht automatisch bessere Ergebnisse, aber sie steht für Verlässlichkeit, methodisches Vorgehen und Orientierung an den Bedürfnissen der Nutzenden. UX-Professionals stellen sicher, dass Lösungen nicht irritieren, sondern verständlich sind und echten Mehrwert bringen. Für Produktteams bedeutet diese Entwicklung, dass die Zusammenarbeit mit UX-Professionals an Bedeutung gewinnt. Product Owner, Product Manager oder Product Leads profitieren von Rollen, die Klarheit in der Gestaltung schaffen, auch wenn KI immer mehr Aufgaben übernimmt. Statt Spezialisierungen aufzulösen, entsteht ein neues Zusammenspiel von Generalisten, Tools und spezifischem Fachwissen. Entscheidend bleibt, dass Produkte menschenzentriert gestaltet werden; egal, wie stark Maschinen an ihrer Entstehung beteiligt sind. Thomas denkt, dass UX-Professionals sich zu „KI-Natives“ entwickeln müssen, ohne ihren Kernauftrag zu verlieren: für Menschen zu gestalten. Die Rolle verändert sich, bleibt aber essenziell für den Erfolg von Produkten. Denn am Ende zählt nicht, wie schnell etwas produziert werden kann, sondern ob es verständlich, zugänglich und nützlich ist.

Sprintziele gehören zu den stärksten Werkzeugen im Scrum-Framework. Dominique und Oliver sprechen in dieser Folge darüber, wie es Teams gelingt, Sprintziele so zu etablieren, dass sie Orientierung geben, Wirkung entfalten und Vertrauen schaffen. Ein Sprintziel ist schließlich mehr als eine Pflichtübung im Sprint Planning. Richtig eingesetzt, schafft es Klarheit über das „Warum“ der nächsten Iteration und verbindet die tägliche Arbeit mit der Produktvision. Vielen Teams fällt die Nutzung von Sprintzielen jedoch schwer. Häufig gibt es gar kein Ziel oder es bleibt auf der Ebene von Aufgabenlisten stecken. Statt echter Wirkung wird dann nur Output gemessen. Die Folge: wenig Fokus, kaum Begeisterung bei Stakeholdern und sinkendes Vertrauen in den Wert von Sprintzielen. Doch gerade hier liegt der Hebel. Ein gut formuliertes Sprintziel richtet die Arbeit am Outcome aus. Es beantwortet die Frage, welchen Mehrwert das Team in den kommenden zwei Wochen schaffen will und gibt damit eine klare Orientierung für Entscheidungen im Sprint. Statt einer Sammlung von Backlog-Items entsteht ein gemeinsamer Fokus. Im Daily oder im Review lässt sich damit jederzeit prüfen, ob die Arbeit noch auf das eigentliche Ziel einzahlt. Dominique und Oliver machen aber auch deutlich, dass Sprintziele eben nicht im stillen Kämmerlein entstehen sollten. Entscheidend ist die gemeinsame Gestaltung mit den Developern. Wer das Ziel aktiv mitformuliert, wird es auch eher als eigenes Commitment ansehen. So entsteht nicht nur mehr Akzeptanz, sondern auch die Bereitschaft, externe Einflüsse auszuhalten und das Ziel zu verteidigen. Product Owner:innen bringen dabei den strategischen Rahmen ein – etwa Vision, Roadmap oder Product Goal – und öffnen einen Raum, in dem das Team das nächste sinnvolle Ziel bestimmen kann. Ein gutes Sprintziel ist aber auch sichtbar und sie sind im Alltag präsent: in Dailys, in Gesprächen mit Stakeholdern und sogar in der spontanen Antwort auf die Frage „Woran arbeitet ihr gerade?“. Nur so werden sie zu einem lebendigen Orientierungspunkt statt zu einem Protokolleintrag. Wenn ein Team das gemeinsam vereinbarte Sprintziel erreicht, gilt es, diesen Erfolg sichtbar zu feiern; nicht die Anzahl der erledigten Backlog-Items, sondern den erzielten Mehrwert. Gerade im Sprint Review eröffnet das die Chance, Stakeholder zu begeistern und ihnen zu zeigen, warum sich die investierte Arbeit gelohnt hat. So wird das Konzept Sprintziele gestärkt und gewinnt wieder Vertrauen. Zusammengefasst helfen Sprintziele Teams dabei, sich auf das Wesentliche zu konzentrieren, Entscheidungen leichter zu treffen und Stakeholder einzubeziehen. Wer sie konsequent auf Outcome ausrichtet, gemeinsam gestaltet und sichtbar macht, etabliert ein Instrument, das weit mehr ist als eine Formalität. Es ist ein Kompass, der Produktteams eine gemeinsame, wetvolle Richtung gibt.

Tim spricht in dieser Folge mit Marc Roulet von sevdesk darüber, warum bessere Metriken & KPIs den Unterschied machen, wenn es um gute Produktentscheidungen geht. Beide erleben in ihrer Arbeit immer wieder, dass Organisationen Zahlen erheben, die zwar schnell verfügbar sind, aber wenig darüber aussagen, ob ein Produkt wirklich Nutzen stiftet. Marc Roulet ist ein erfahrener Experte im Bereich Analytics und Metriken und bei sevdesk verantwortlich für Data und Analytics. Er hat in ähnlichen Rollen u.a. auch schon bei ebay, mobile.de und XING Erfahrung gesammelt. Somit ist er ein sehr passender Gesprächspartner für dieses Thema Viele Teams orientieren sich an einfachen Kennzahlen wie Story Points oder Anzahl ausgelieferter Features. Das zeigt den "Fleiß" - i.S. von Output, sagt aber kaum etwas über Wirkung. Bessere Metriken schauen auf Outcomes und helfen zu erkennen, ob Kundinnen und Kunden tatsächlich profitieren. Wer das ernst nimmt, stellt fest, dass nicht jede neue Funktion Wert für die Nutzer schafft – und dass auch das Weglassen eine wichtige Entscheidung sein kann. Metriken sind kein starres System, das man einmal definiert und dann abarbeitet. Sie entfalten ihren Wert erst, wenn Teams regelmäßig hinschauen, sie diskutieren und ggf. anpassen - also aktiv mit ihnen arbeiten. So entsteht ein gemeinsames Verständnis, worauf es wirklich ankommt. Oft geht es darum, Hypothesen zu prüfen: Führt eine bestimmte Änderung tatsächlich zu mehr Nutzung? Verbessert sie ein relevantes Kundenerlebnis? Oder verpufft der Effekt? Gerade für Product Owner liegt hier eine Chance. Sie sind nah an den Entscheidungen und können dafür sorgen, dass Gespräche über bessere Metriken nicht an der Oberfläche bleiben. Es geht nicht darum, Zahlen zu liefern, die gut aussehen, sondern um eine Grundlage, die schwierige Fragen und Entscheidungen ermöglicht. Was bedeutet Erfolg für unser Produkt? Wie messen wir Fortschritt, der über Auslastung und Geschwindigkeit hinausgeht und in Richtung unserer Produktvision führt? Wer sich auf diesen Weg einlässt, wird merken, dass bessere Metriken Orientierung geben. Sie bringen Klarheit in Diskussionen mit Stakeholdern, machen Annahmen transparent und helfen Teams, bewusster zu entscheiden. So wird Produktentwicklung weniger zu einer Abfolge von Aktivitäten und mehr zu einem Prozess von Wertgenerierung, der echten Unterschied macht. Das Video von Marcs Talk auf der Product at Heart können wir zu diesem Thema nur empfehlen. Hier der Link zu seinem Talk im Video-Archiv der diesjährigen Product at Heart. In dieser Episode verweisen wir auf diese älteren Folgen des Podcasts: - Data-Fluent Product Manager mit Büşra Coşkuner - Klarheit als Superpower für Produktmenschen mit Arne Kittler Ihr könnt mit Marc Roulet gerne direkt in Kontakt treten und weitere Fragen klären. Am besten kontaktiert ihr in über sein LinkedIn-Profil. Was für Erfahrungen in der Arbeit mit Metriken und KPIs hast du gemacht? Wie arbeitet ihr in eurem Produktteam mit dem Analytics und BI-Team zusammen? Teilt eure Erlebnisse mit uns und anderen Produktmenschen unter diesem Blogpost oder auf unserer LinkedIn Seite und lasst uns gemeinsam daran wachsen!

In dieser Folge sprechen Oliver und Dominique über ein Thema, das oft unterschätzt wird und trotzdem die Arbeit eines ganzen Produktteams prägen kann: die Produktvision. Beide erleben in ihrer Arbeit immer wieder, wie stark der Unterschied ist zwischen einer Vision, die nur an einer Wand hängt, und einer, die tatsächlich im Team gelebt wird. Eine gute Produktvision gibt nämlich Richtung und Sinn. Sie hilft, Entscheidungen einzuordnen, Prioritäten zu setzen und auch schwierige Diskussionen schneller aufzulösen. Vor allem schafft sie ein gemeinsames Verständnis darüber, wofür das Team eigentlich antritt. Doch genau das ist die Herausforderung: eine Vision so zu entwickeln, dass sie nicht nur von Product Owner oder Führung formuliert wird, sondern dass das gesamte Team sie verinnerlicht. Es ist wichtig, dass Teams gemeinsam an ihrer Produktvision arbeiten. Dabei geht es nicht um den perfekten Satz, sondern darum, im Austausch ein Bild zu schaffen, das alle teilen können. Solche Prozesse machen eine Vision greifbar und verhindern, dass sie als reine Management-Vorgabe wahrgenommen wird. Wer von Anfang an beteiligt ist, fühlt sich verbunden und handelt eher danach. Damit eine Produktvision nach der Entwicklung aber nicht in Vergessenheit gerät, braucht es mehr als nur einen guten Start. Sie muss regelmäßig im Alltag auftauchen: im Planning, wenn über Prioritäten entschieden wird, im Review, wenn Ergebnisse eingeordnet werden, oder auch in Retrospektiven, wenn das Team reflektiert, ob es auf dem richtigen Weg ist. Eine Vision, die so verankert ist, bleibt lebendig und entwickelt sich weiter, ohne ihre Orientierungskraft zu verlieren. Besonders wertvoll wird eine Produktvision auch beim Onboarding. Neue Teammitglieder verstehen schneller, warum das Produkt existiert und welchen Unterschied es macht. Wenn nicht nur Product Owner:innen, sondern auch Entwicklerinnen und Designer:innen die Vision erzählen können, zeigt das, dass sie wirklich Teil der gemeinsamen Arbeit geworden ist. Oliver und Dominique machen deutlich: Eine Produktvision entfaltet ihre Wirkung nicht durch Worte allein, sondern dadurch, dass sie im Team geteilt und immer wieder neu mit Leben gefüllt wird. Sie ist der Kompass, der allen hilft, auch in komplexen Situationen die Richtung nicht zu verlieren. Wenn euch das Thema Produktvisionen interessiert findet ihr hier noch mehr passende Folgen: Wie die Produktvision hilft, Product Ownern eine Richtung zu geben (https://produktwerker.de/wie-die-produktvision-hilft-product-ownern-eine-richtung-zu-geben/) Warum Product Owner die Unternehmensvision kennen sollten (https://produktwerker.de/unternehmensvision/)

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 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?

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.

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

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. 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.

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 welch

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 (just-product.de) - Product Masterclass Angebot (product-masterclass.com) 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.

Was zeichnet gute Conversational AI eigentlich aus? Welche Prinzipen braucht 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

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. Link zum deutschsprachigen Product Owner Online Course: https://scrumacademy.onfastspring.com/product-owner-online-course-de?source=produktwerker Weiterführende Infos zum neuen Zertifizierungsansatz der Agile Academy gibt es hier: https://www.agile-academy.com/de/service/introducing-certified-by-agile-academy/ Oliver Winter bietet bereits schon Zertifizierungstrainings an (Level 1 & 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/.

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.

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.