Episodios

  • Was ist für POs im Scrum Guide Expansion Pack drin?
    Jul 14 2025
    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
    Más Menos
    50 m
  • Vom Projekt- zum Produktmodus
    Jul 7 2025
    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.
    Más Menos
    48 m
  • Designprinzipien für Conversational AI
    Jun 30 2025
    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
    Más Menos
    36 m
  • Anwendungsnahe Weiterbildung - für mehr Erfolg als Product Owner
    Jun 23 2025
    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/.
    Más Menos
    57 m
  • Was bedeuten die Scrum Werte für Product Owner - und wie lebst du sie im Alltag
    Jun 16 2025
    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.
    Más Menos
    39 m
  • Strukturen, die Produktentwicklung behindern – und was ihr dagegen tun könnt
    Jun 9 2025
    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.
    Más Menos
    45 m
  • Doppelrolle als PO und Scrum Master - was tun?
    Jun 2 2025
    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.
    Más Menos
    38 m
  • Visuelle Methoden in der Produktentwicklung
    May 26 2025
    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 Episode 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.
    Más Menos
    47 m