Épisodes

  • User Research operationalisieren

    User Research operationalisieren
    Dec 15 2025
    In dieser Folge sprechen Anne Görs, Senior User Researcher, Founder & Managing Director bei der leefs CX GmbH, und Dominique darüber, wie sich User Research operationalisieren lässt, sodass er dauerhaft Teil der Produktarbeit wird. Ausgangspunkt ist die Beobachtung, dass viele Teams User Research grundsätzlich schätzen, ihn aber als zu langsam, zu aufwendig oder störend für schnelle Entscheidungen wahrnehmen. Genau hier setzt der Gedanke an, User Research operationalisieren zu wollen und ihn so in den Arbeitsfluss einzubetten, dass er Entscheidungen unterstützt statt sie "auszubremsen". User Research operationalisieren bedeutet, Forschung nicht als einmaliges Projekt zu denken, sondern als wiederkehrenden, verlässlichen Prozess. Es geht darum, Strukturen zu schaffen, die Wiederholbarkeit ermöglichen, ohne die nötige Flexibilität zu verlieren. Dazu gehören klare Verantwortlichkeiten, abgestimmte Abläufe und ein gemeinsames Verständnis dafür, wofür Erkenntnisse genutzt werden. Forschung wird dadurch planbarer und verliert den Ruf, ein Bremsklotz zu sein. Stattdessen erhöht sie die Wahrscheinlichkeit, mit den getroffenen Entscheidungen tatsächlich Wirkung zu erzielen. Dazu braucht es auch einen bewussten Umgang mit Unsicherheit. User Research liefert schließlich keine Wahrheiten, sondern reduziert Risiken. Wenn Teams und Stakeholder verstehen, dass Forschung dabei hilft, bessere strategische Wetten einzugehen, verändert sich die Akzeptanz spürbar. Entscheidungen basieren dann nicht mehr ausschließlich auf Erfahrung oder Bauchgefühl, sondern auf nachvollziehbaren Erkenntnissen über Nutzer:innen. Das stärkt Vertrauen in den Prozess und in die Menschen, die ihn verantworten. Aber damit das Operationalisieren des User Researchs gelingen kann, braucht es auch Wege, Erkenntnisse so aufzubereiten, dass sie im Alltag genutzt werden. Forschung entfaltet nur dann ihren Wert, wenn sie in konkrete Anforderungen, Prioritäten oder Entscheidungen übersetzt wird. Das erfordert enge Zusammenarbeit mit den Produktteams und ein Verständnis dafür, welche Form von Ergebnissen ihnen wirklich hilft. Einheitliche Templates oder starre Reportstrukturen greifen hier oft zu kurz. Entscheidend ist also, dass Erkenntnisse anschlussfähig sind und dort ankommen, wo sie gebraucht werden. Teams profitieren davon, selbst beteiligt zu sein, zuzuhören, Fragen zu stellen und Forschung mitzuerleben. Diese Beteiligung erhöht die Akzeptanz der Ergebnisse und sorgt dafür, dass Erkenntnisse nicht infrage gestellt werden, nur weil sie unbequem sind. Gleichzeitig braucht es fachliche Begleitung, um Qualität zu sichern und Fehlinterpretationen zu vermeiden. User Research operationalisieren heißt daher am Ende auch, kulturelle Voraussetzungen zu schaffen. Eine Organisation muss bereit sein, mit Feedback umzugehen, das bestehende Annahmen infrage stellt. Forschung deckt Schwächen auf und zeigt, wo Ideen nicht wie erwartet funktionieren. Wer das als Chance zur Verbesserung versteht, schafft Raum für kontinuierliches Lernen und bessere Produkte. Der Blick richtet sich damit weniger auf einzelne Methoden als auf ein Zusammenspiel aus Haltung, Prozessen und Verantwortung. Wenn User Research dauerhaft Teil der Produktentwicklung wird, unterstützt er Entscheidungen, reduziert Risiken und hilft Teams, näher an den tatsächlichen Bedürfnissen ihrer Nutzer:innen zu arbeiten. Genau dort entfaltet operationalisierter User Research seine größte Wirkung.
    Voir plus Voir moins
    31 min
  • Was kann ich selber tun, um mehr Ownership zu erhalten?

    Was kann ich selber tun, um mehr Ownership zu erhalten?
    Dec 8 2025
    Viele Menschen starten motiviert in ihrer Rolle und stellen dann fest, dass ihnen Entscheidungen entzogen werden oder dass bestimmte Aufgaben weiterhin von anderen übernommen werden. Der Frust wächst, weil der Wunsch nach Verantwortung da ist, aber die Strukturen nicht mitziehen. Genau daran knüpft das Gespräch in dieser Folge an und zeigt Wege, wie mehr Ownership nicht nur gefordert, sondern im Alltag schrittweise aufgebaut wird. Direkt zu Beginn wird klar, dass ein wichtiger Aspekt für mehr Ownership fachliche Tiefe ist. Menschen, die die Kund:innen, den Markt, das eigene Produkt und relevante Wettbewerbsangebote sehr gut verstehen, entwickeln ein anderes Standing. Sie können Diskussionen auf eine faktische Ebene bringen und wegführen vom Raum der reinen Meinungen. Das öffnet Türen, weil Entscheidungen nachvollziehbarer werden und Stakeholder:innen merken, dass jemand nicht nur koordinieren möchte, sondern echte Produktverantwortung übernimmt. Fachliche Klarheit wirkt auf die Organisation, auch wenn sie anfangs kaum Freiraum bietet. Damit verbunden ist aber auch der Umgang mit Unsicherheit. Jede Produktentscheidung bleibt eine Wette. Wer diese Wette sauber beschreibt, ihre Risiken benennt und darauf achtet, auf welcher Datengrundlage entschieden wird, tritt automatisch verantwortlicher auf. Das Gespräch zeigt gut, wie stark sich die Wirkung eines Product Owners verändert, sobald Entscheidungen nicht mehr als absolute Wahrheiten präsentiert werden, sondern als reflektierte Schritte mit nachvollziehbarer Logik. Viele Stakeholder:innen reagieren positiv darauf, weil sie erkennen, dass Entscheidungen begleitet werden und nicht blind getroffen werden. Das zeigt, dass Kommunikation eine wichtige Rolle spielt. Klare Sprache erzeugt Klarheit über Risiken, Annahmen und Wissenslücken. Sie macht sichtbar, welche Informationen fehlen und wo die Organisation Prioritäten setzen sollte. Es steckt viel Ownership darin, offen zu sagen, welche Informationen fehlen, welche Wahrscheinlichkeiten realistisch sind und welche Konsequenzen bestimmte Wege haben. Gute Kommunikation heißt in diesem Kontext nicht, Konflikte zu vermeiden, sondern Orientierung zu schaffen. Aber am Ende geht es um die eigene Haltung. Ownership entsteht nicht dadurch, dass jemand sie verleiht. Sie wächst durch konsequentes Handeln. Dazu gehört, aktiv Informationen zu suchen, Discovery voranzutreiben, Entscheidungen einzufordern und Transparenz darüber herzustellen, was möglich ist und wo Grenzen liegen. Wer sein Umfeld so begleitet, verändert Schritt für Schritt die Wahrnehmung der eigenen Rolle und schafft die Grundlage für echte Product Ownership, selbst wenn die Organisation noch im alten Denken steckt.
    Voir plus Voir moins
    39 min
  • Vom Projektmanager zum Product Owner - keine einfache Lernreise

    Vom Projektmanager zum Product Owner - keine einfache Lernreise
    Dec 1 2025
    n dieser Folge sprechen Dominique und Tim gemeinsam über die Lernreise vom Projektmanager zum Product Owner. Beide bringen eigene Erfahrungen aus der Projektwelt und aus dem Projektmanagement mit und beleuchten, wie stark sich Perspektiven und Entscheidungen verändern, sobald man Verantwortung für ein Produkt statt für ein Projekt hat. Was sich im ersten Moment wie ein natürlicher Übergang anfühlt, entpuppt sich im Alltag als echter Perspektivwechsel, der viel Umlernen, Mut und Neugier erfordert. Viele Menschen, die vom Projektmanager zum Product Owner wechseln, bringen ein ausgeprägtes Gefühl für Struktur und Verlässlichkeit mit. Das hilft in der Zusammenarbeit mit Stakeholdern und in Gesprächen rund um Erwartungen, Risiken und Entscheidungen. Der vertraute Blick auf Zeit, Budget und Umfang gibt Sicherheit, die im Produktalltag weiterhin wertvoll sein kann. Gleichzeitig spüren viele aber schnell, wie anspruchsvoll es ist, nicht mehr den Ablauf eines Vorhabens zu steuern, sondern ein Produkt so zu entwickeln, dass es echten Wert erzeugt. Entscheidungen entstehen nicht mehr durch Freigaben von außen, sondern aus einem eigenen Mandat heraus. Das ist eine neue Verantwortung und eine ungewohnte Freiheit. Die größte Veränderung beginnt im Kopf. Wer vom Projektmanager zum Product Owner wechselt, erlebt, wie eng alte Muster sitzen. Das Bedürfnis, alles zu organisieren und jede Unsicherheit zu beseitigen, meldet sich sofort zurück, sobald Druck entsteht. Die Umgebung trägt oft ihren Teil dazu bei. Stakeholder kennen die neue Rolle noch nicht gut und behandeln die Person weiter so wie früher. Die Versuchung ist groß, wieder zu schätzen, wieder zuzusagen, wieder in die alte Rolle zu rutschen. Doch genau hier entsteht der entscheidende Lernmoment. Die neue Rolle braucht Raum, Zeit und Unterstützung, damit sie wirken kann. Es ist sehr hilfreich die Verantwortung im Produkt nicht mit der Verantwortung für das Team zu verwechseln. Kontrolle loszulassen und Selbstorganisation zuzulassen gehört zu den schwersten Schritten. Gleichzeitig entsteht dadurch ein Arbeitsumfeld, in dem ein Team eigene Entscheidungen treffen kann. Und genau dort gewinnt ein Product Owner die Energie zurück, die für Discovery, Wertschätzung von Nutzerbedürfnissen und Experimente nötig ist. Wer vom Projektmanager zum Product Owner wird, erlebt oft zum ersten Mal, wie sich Fokus auf Wirkung anfühlt und warum es sich lohnt, alte Routinen zu hinterfragen. Viele kennen aus ihrer Projektvergangenheit sogenannte Lessons Learned, doch sie passieren meist spät und oft ohne Anschluss. Im Produktalltag zählt etwas anderes. Kontinuität. Eine Retro, die regelmäßig stattfindet, unterstützt das Team dabei, wach zu bleiben, zu lernen und das eigene Arbeiten bewusster zu gestalten. Diese Haltung ist ein Kern der Produktarbeit und ein wichtiger Teil der neuen Verantwortlichkeit. Zum Abschluss betonen Dominique und Tim noch einmal, dass dieser Wechsel kein automatischer Schritt ist. Wer vom Projektmanager zum Product Owner wechselt, braucht Unterstützung und ein Umfeld, das bereit ist mitzuwachsen. Rollen verändern sich nicht durch neue Titel, sondern durch gemeinsames Lernen. Und genau dafür möchten wir mit unserem Podcast Raum schaffen. Auf diese älteren Folgen nehmen Tim und Dominique im Gespräch Bezug: - Welchen Einfluss auf die Retrospektive hat ein Product Owner? - Dein Freund der Scrum Master Habt ihr auch Erfahrungen gemacht auf dem Weg vom Projektleiter bzw. Projektmanager zum Product Owner? Oder habt ihr einen solchen Wandel innerhalb eures Unternehmen beobachten können? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite.
    Voir plus Voir moins
    46 min
  • Emotionen in der Produktarbeit

    Emotionen in der Produktarbeit
    Nov 24 2025
    In dieser Folge spricht Dominique mit Stephanie Weber darüber, wie präsent Emotionen in der Produktarbeit sind und wie stark sie das tägliche Handeln beeinflussen. Stephanie bringt ihre Erfahrung als Head of UX Design bei Fielmann ein und kann bestätigen, dass Emotionen in der Produktarbeit weit mehr sind als ein weiches Thema. Beide haben erlebt, wie sehr Entscheidungen, Zusammenarbeit und Nutzerverhalten durch Gefühle geprägt werden und die gemeinsame Frage, wie wir bewusster mit Emotionen in der Produktarbeit umgehen können, zieht sich durch das gesamte Gespräch. Es kommt beispielsweise sehr oft vor, dass Angst den Raum verengt. Angst taucht auf, wenn neue Ideen gewagt werden sollen, wenn Entscheidungen unsicher wirken oder wenn Menschen befürchten, im Team nicht ernst genommen zu werden. Dabei ist Psychologische Sicherheit eine der Grundlagen dafür, dass Kreativität entstehen kann. Methoden wie Brainwriting oder die Kopfstandmethode helfen Teams, vorsichtigere Stimmen sichtbarer zu machen und die üblichen Muster offener Brainstormings zu durchbrechen. Angst entsteht auch bei Nutzerinnen und Nutzern, etwa wenn neue Technologien unerwartet wirken. Und gerade dort kann Gestaltung helfen, etwa wenn ein normalerweise blitzschneller Prozess kleine Verzögerungen erfährt, um ihn für Kunden verständlicher wirken lassen und Vertrauen zu schaffen. Stephanie spricht auch über Reibung als bewussten Teil von Produktarbeit. Reibung ist für sie nicht unbedingt etwas schlechtes, sondern ein Werkzeug, um Skepsis aufzufangen und Orientierung zu geben. Im Team entsteht Reibung durch unterschiedliche Denkweisen und Persönlichkeiten. Wenn diese Vielfalt nicht eingeengt, sondern gezielt genutzt wird, werden Ideen robuster und Entscheidungen fundierter. Kreativmethoden, bei denen Ideen weitergereicht und weiterentwickelt werden, zeigen, wie wertvoll diese Reibung ist. Scham taucht ebenfalls häufig in der Produktarbeit auf, im Team wie bei Nutzerinnen und Nutzern. Stephanie beschreibt, wie belastend unstrukturierte Gruppenmethoden sein können, vor allem für eher introvertierte und ruhige Menschen. Struktur schafft hier Raum für Beteiligung ohne Scham. Das Manual of Me kann beispielsweise im Team geteilt werden, um persönliche Bedürfnisse und Arbeitsweisen zu verdeutlichen und Unsicherheiten greifbarer zu machen. Und auch bei Kunden im Laden zeigt sich Scham deutlich, etwa wenn Menschen mit hoher Sehstärke eine Fassung testen und sich im Spiegel gar nicht erkennen können. Der Moment wirkt klein, wird für die betroffenen Personen aber schnell unangenehm. Genau solche Beobachtungen helfen, Produkte zu entwickeln, die sich anfühlen wie Unterstützung und nicht wie ein Hindernis. Langeweile wirkt auf den ersten Blick fehl am Platz, spielt aber in der Produktarbeit eine wichtige Rolle. Stephanie macht deutlich, dass Pausen, langsame Momente und gedankliches Abschweifen essenziell sind, weil sie Raum für neue Verbindungen und Ideen schaffen. Wer ständig durch Meetings, Chats und Aufgaben getrieben wird, nimmt dem Gehirn die Möglichkeit, Dinge sortiert entstehen zu lassen. Kreatives Denken entsteht oft zwischen zwei Tätigkeiten und selten dann, wenn wir es erzwingen. Teams profitieren deshalb stark davon, wenn Langeweile nicht als Mangel an Produktivität verstanden wird, sondern als fruchtbarer Teil der Arbeit. Emotionen sind in der Produktarbeit unvermeidbar. Sie gehören zu Teams, Entscheidungen, Nutzerverhalten und Produkten. Sie lassen sich nicht abschalten, wenn wir morgens den Rechner einschalten. Je bewusster wir mit ihnen umgehen, desto leichter fällt es, gute Entscheidungen zu treffen, mutige Ideen zuzulassen und Nutzerbedürfnisse wirklich zu verstehen. Genau darum lohnt es sich, Emotionen in der Produktarbeit nicht als Störung zu sehen, sondern sie zu unserem Vorteil zu nutzen.
    Voir plus Voir moins
    44 min
  • Wie hat sich die PO/PM/UX Landschaft in den letzten 6 Jahren verändert?

    Wie hat sich die PO/PM/UX Landschaft in den letzten 6 Jahren verändert?
    Nov 17 2025
    In Folge 300 feiern wir ein großes Jubiläum Dominique, Oliver und Tim blicken zurück auf 6 Jahre Podcast und mehr als 300 Gespräche mit und für Product Owner, Produktmanager:innen und alle mit Verantwortung für gute digitale Produkte. Dabei geht’s um zentrale Fragen wie: • Wie hat sich die Erwartung an Product Owner, PM & UX verändert? • Warum verschiebt sich der Fokus weg von Frameworks hin zu echter Produktverantwortung? • Wieso ist Discovery heute fester Bestandteil guter Produktarbeit? • Was bedeutet die Durchlässigkeit zwischen PO, PM und UX für die Teamarbeit? • Warum stoßen viele POs trotz wachsender Erfahrung weiterhin an Grenzen? Die drei reflektieren die wichtigsten Entwicklungen in der Community – von der Pandemie und Remote-Lernen über veränderte Rollenbilder bis zu den Herausforderungen in skalierten Organisationen. Ein Rückblick, der Mut macht und Orientierung gibt – für alle, die Wirkung erzielen statt nur liefern wollen. Diese Folge ist eine klare Empfehlung für alle, die sich fragen, wie sich die Rolle des Product Owners weiterentwickelt – und wie sie selbst Teil dieser Entwicklung sein können.
    Voir plus Voir moins
    59 min
  • Welchen Einfluss auf die Retrospektive hat ein Product Owner?

    Welchen Einfluss auf die Retrospektive hat ein Product Owner?
    Nov 10 2025
    Tim spricht in dieser Folge mit Bernd Joussen über den Einfluss auf die Retrospektive, den Product Owner tatsächlich haben. Bernd ist erfahrener Produkt- und Projektmanager, Scrum Master und Agile Coach und war schon mehrfach Gast im Podcast. Beide erleben in ihrer Arbeit mit Teams, dass viele Product Owner den Raum der Retro missverstehen. Manche treten zu dominant auf und hemmen den Austausch. Andere ziehen sich so weit zurück, dass sie kaum Wirkung entfalten. Dabei ist die Retrospektive ein gemeinsamer Ort des Lernens. Der Product Owner gehört dorthin, weil er Teil des Teams ist und mit seinem Verhalten darüber entscheidet, wie offen gesprochen werden kann. Bernd beschreibt, dass eine Retro ohne Vertrauen keine Wirkung zeigt. Wenn Teams einmal darum bitten, eine Runde ohne Product Owner durchzuführen, sei das ein Signal, das ernst genommen werden sollte. Kein Anlass zur Verteidigung, sondern zur Selbstreflexion. Denn Vertrauen entsteht nicht durch Argumente, sondern durch Haltung. Wer als Product Owner offen zuhört, statt zu bewerten, gibt dem Team die Sicherheit, auch heikle Themen anzusprechen. In vielen Organisationen hängt der Einfluss auf die Retrospektive stark von der Persönlichkeit des Product Owners ab. Wer laut ist, prägt die Dynamik schnell. Wer zurückhaltend ist, verliert an Gewicht. Beides kann den Austausch verzerren. Ein guter Product Owner kennt die Wirkung seiner Präsenz und achtet darauf, Raum zu geben. Bernd betont, dass die Moderation des Scrum Masters hier entscheidend ist. Sie schafft Balance zwischen allen Stimmen und schützt den Raum vor einseitigen Perspektiven. Der Einfluss auf die Retrospektive zeigt sich nicht in Redebeiträgen, sondern in Haltung. Ein Product Owner, der echtes Interesse am Team zeigt, Fragen stellt und neugierig bleibt, trägt mehr zur Verbesserung bei als jemand, der Ergebnisse einfordert. Gute Retrospektiven entstehen, wenn alle gemeinsam Verantwortung übernehmen. Wenn der Product Owner das Team unterstützt, Lösungen zu finden, statt sie vorzugeben. Tim beschreibt, dass gerade in produktorientierten Teams die Retro oft zu stark auf Prozesse schaut und zu wenig auf Wirkung. Dabei bietet sie die Chance, über Outcomes zu sprechen, über den Beitrag des Teams zum Produktwert. Wenn der Product Owner diesen Blick einbringt, erweitert er die Perspektive, ohne den Rahmen zu sprengen. Dann wird die Retrospektive zu einem Ort, an dem Teamleistung und Produkterfolg zusammenfinden. Bernd sieht in reifen Teams eine Selbstverständlichkeit, mit der Product Owner und Scrum Master gemeinsam für diese Qualität sorgen. Sie verstehen sich als Tandem, das das Team befähigt, eigene Lösungen zu entwickeln. Wo diese Verbindung fehlt, bleibt die Retro oberflächlich. Gute Zusammenarbeit zwischen Scrum Master und Product Owner sorgt dafür, dass Themen wie Vertrauen, Konflikte oder Verantwortung auch mit Blick auf den Produkterfolg besprochen werden. Der Einfluss auf die Retrospektive hängt also davon ab, wie bewusst ein Product Owner seine Rolle lebt. Wer mit Neugier und Ruhe in die Retro geht, stärkt das gemeinsame Lernen. Wer sich als Teil des Teams begreift, fördert Offenheit. Und wer Verantwortung für die Wirkung seiner Worte übernimmt, schafft die Grundlage für Weiterentwicklung. Gute Retrospektiven entstehen dort, wo Menschen zuhören, lernen und handeln – gemeinsam und mit echtem Interesse aneinander. Frühere Episoden mit Bernd Joussen in diesem Podcast: - Konflikte mit Stakeholdern meistern - von Spannungen zu Lösungen - Herausforderungen zwischen Product Owner und Developer Wenn ihr direkt mit Bernd Joussen in Kontakt kommen möchtet, erreicht ihr ihn über sein LinkedIn-Profil. Weitere Informationen über Bernd Joussen und sein Angebot als Konfliktbegleiter, Experte für Retrospektiven mit Führungskräften und als Teamentwickler findet ihr auf seiner Webseite der-teamdynamo.de.
    Voir plus Voir moins
    48 min
  • Wie viel Zeit darf User Story Erstellung kosten - hilft uns KI dabei?

    Wie viel Zeit darf User Story Erstellung kosten - hilft uns KI dabei?
    Nov 3 2025
    Wie viel Zeit sollten Product Owner eigentlich in das Schreiben von User Stories investieren? Wenn der Kalender voll ist und die To-do-Liste überquillt, wirkt das Story-Schreiben schnell wie eine lästige Pflicht. Viele sehen es als reine Schreibarbeit. Doch in Wahrheit ist es vor allem Denk- und Teamarbeit. Eine gute User Story entsteht nicht allein am Schreibtisch, sondern im Gespräch. Sie ist das sichtbare Ergebnis gemeinsamer Klärung; ein Zeichen dafür, dass sich ein Team verstanden hat. Wer User Stories schreibt, arbeitet also nicht an Texten, sondern am gemeinsamen Verständnis. Eine Story ist kein Dokument, sondern ein Kommunikationswerkzeug. Sie erinnert an ein Gespräch, in dem klar wurde, welches Nutzerproblem wirklich gelöst werden soll. Manche Teams versuchen, Sicherheit durch besonders ausführliche Formulierungen zu schaffen. Dabei verlieren sie leicht das eigentliche Ziel aus den Augen. Gute User Stories entstehen, wenn Teams gemeinsam begreifen, worum es geht – nicht, wenn sie jedes Detail zu Papier bringen. Tim beschreibt User Stories als Einladung zum Dialog. Sie sollen Empathie für Nutzer:innen wecken und den Blick auf deren Bedürfnisse richten. In dieser Haltung wird das Schreiben von Stories zu einem Werkzeug, das Orientierung schafft. Wenn Teams verstehen, warum etwas wichtig ist, finden sie auch den passenden Weg dorthin. Dann reicht manchmal ein einziger Satz, um eine Idee zu verankern und das Gespräch darüber am Laufen zu halten. Dominique beobachtet, dass Organisationen sehr unterschiedlich mit User Stories umgehen. In großen Unternehmen wird oft zu viel dokumentiert, vielleicht, weil man es immer so gemacht hat. Startups dagegen schreiben häufig zu wenig auf. Beides zeigt ein Ungleichgewicht zwischen Vertrauen und Kontrolle. Ein Team, das seine Prozesse kennt und sich gegenseitig vertraut, braucht keine langen Texte. Es verlässt sich auf Dialog und gemeinsame Verantwortung. Wie viel Zeit also in die Story-Erstellung fließt, hängt stark von der Reife eines Teams ab. Wer schon lange zusammenarbeitet und den Produktkontext kennt, kommt mit wenigen Worten aus. Neue Teams dagegen brauchen mehr Austausch, um ein gemeinsames Verständnis aufzubauen. In jedem Fall sollte die Energie lieber in Nachdenken und Reflexion fließen als in das Polieren von Formulierungen. Hilfreich ist die bekannte Zehn-Prozent-Regel: Rund zehn Prozent der Sprintzeit sollten in die Erstellung und das gemeinsame Refinement des Backlogs investiert werden. Diese Zeit zahlt sich aus, weil sie Klarheit schafft – über Ziele, Annahmen und Prioritäten. Wer hier spart, zahlt später mit Missverständnissen und Nacharbeit. Auch Künstliche Intelligenz kann dabei unterstützen, etwa durch Strukturvorschläge oder Formulierungsideen. Doch sie ersetzt kein gemeinsames Denken. Eine automatisch erzeugte Story ist noch keine Story, solange das Team nicht darüber spricht. KI kann inspirieren, aber kein echtes Verständnis schaffen und am Ende braucht es immer jemanden, der beurteilen kann, ob das Ergebnis wirklich gut ist. Gute User Stories entstehen also in Gesprächen, nicht in Tools. Sie schaffen ein gemeinsames Bild des Nutzerproblems und machen Produktentwicklung wirkungsvoller. Wer sich Zeit für den Austausch nimmt, gewinnt Klarheit und diese Klarheit ist die beste Grundlage für jedes gute Produkt.
    Voir plus Voir moins
    41 min
  • Entscheidungen vertreten, die mir als Product Owner nicht gefallen

    Entscheidungen vertreten, die mir als Product Owner nicht gefallen
    Oct 27 2025
    In dieser Folge sprechen Oliver und Tim über eine Situation, die vielen Product Ownern vertraut sein dürfte. Eine Entscheidung wird (z.B. auf höherer Ebene) getroffen, die sie so nicht nachvollziehen können oder mit der sie schlicht nicht einverstanden sind. Und trotzdem müssen sie solche Entscheidungen vertreten, z.B. gegenüber ihrem Team. Solche Momente fordern Haltung und eine gewisse Aufmerksamkeit. Als Product Owner steht man oft zwischen verschiedenen Erwartungen von Management, Team und Stakeholdern. Wenn eine Entscheidung fällt, die man selbst nicht getroffen hat, entsteht leicht ein innerer Konflikt. Soll ich loyal sein oder kritisch bleiben? Wie kann ich nach außen geschlossen auftreten, ohne mich selbst zu verbiegen? Oliver und Tim machen im Gespräch deutlich, dass Entscheidungen vertreten nicht bedeutet, sie unreflektiert zu übernehmen. Es geht darum, Verantwortung zu tragen für den gemeinsamen Kurs, auch wenn man selbst anders entschieden hätte. Gerade das unterscheidet reife Product Owner von reaktiven. Sie wissen, dass Produktentwicklung ein Teamsport ist und dass Entscheidungen immer im Zusammenspiel vieler Perspektiven entstehen. Das bedeutet jedoch nicht, dass man alles einfach akzeptieren muss. Produktverantwortung bleibt auch in solchen Momenten bestehen. Wer Entscheidungen vertreten soll, darf sie hinterfragen, verstehen und einordnen. Erst wenn ich nachvollziehen kann, warum ein bestimmter Weg eingeschlagen wird, kann ich ihn glaubwürdig gegenüber dem Team kommunizieren. Das erfordert Gesprächsbereitschaft und Mut, besonders gegenüber Führungskräften oder Stakeholdern, die schnelle Ergebnisse erwarten. Oliver beschreibt, wie hilfreich es ist, bewusst zwischen der eigenen Meinung und der gemeinsamen Entscheidung zu unterscheiden. Ich darf anderer Meinung sein und trotzdem nach außen klar auftreten. Tim betont, dass Transparenz im Team entscheidend ist. Wenn die Product Owner selbst unsicher wirken, verlieren Teams Orientierung. Offenheit nach innen, Geschlossenheit nach außen. Diese Balance prägt professionelle Product Ownership. Entscheidungen vertreten heißt auch, sich selbst zu reflektieren. Woher kommt mein Widerstand? Geht es um Prinzipien, um persönliche Präferenzen oder um fehlende Informationen? Erst wenn ich das verstehe, kann ich konstruktiv handeln. Manchmal hilft es, die Entscheidung als Experiment zu betrachten. Nicht jede falsche Richtung ist ein Scheitern, solange ich bereit bin, daraus zu lernen. Für Product Owner ist das ein Lernfeld, das mit der Zeit leichter wird. Denn wer regelmäßig Entscheidungen vertreten muss, die er nicht mag, lernt, zwischen Zustimmung und Verantwortung zu unterscheiden. Und das schafft Vertrauen im Team, bei Stakeholdern und im gesamten Produktumfeld. Auf folgende frühere Episoden dieses Podcasts wurde im Gespräch verwiesen: - Klarheit als Superpower für Produktmenschen (Arne Kittler) - Kluge Entscheidungen treffen mit Decision Poker - Product Owner sind Pokerspieler - Ein Produkt einstellen - der Ramp Down von XING Events (Thomas Gläser) - The Decision Stack - Nein sagen als Product Owner Wenn du selbst regelmäßig Entscheidungen vertreten musst, die dir schwerfallen, bist du damit nicht allein. Lass andere teilhaben. Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns teilst.
    Voir plus Voir moins
    38 min