Die Produktwerker

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.

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.

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.

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

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

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

Klarheit ist für uns Produktmenschen ein entscheidender Faktor, um auch in unsicheren Situationen handlungsfähig zu bleiben. In unserer neuen Podcastfolge spricht Tim mit Arne Kittler – einem erfahrenem Product Leader, langjährigem CPO und Mitgründer der "Product at Heart"-Konferenz – darüber, warum Klarheit nicht bedeutet, alles zu wissen, sondern ein gemeinsames Verständnis zu schaffen, auf dessen Basis Teams ins Handeln kommen. Gerade in der Produktentwicklung arbeiten wir oft mit unvollständigen Informationen. Arne beschreibt Klarheit als bewusste Entscheidung: den Kontext so gut wie möglich zu erfassen und daraus hilfreiche Orientierung abzuleiten – auch wenn absolute Sicherheit nie erreichbar ist. Zusammenarbeit funktioniert nur, wenn wir bereit sind, Unklarheiten aktiv zu klären und gemeinsam tragfähige Annahmen zu entwickeln. Klarheit entsteht nicht von selbst. Sie muss immer wieder neu geschaffen werden, weil sich Rahmenbedingungen verändern. Wer das ignoriert, riskiert, auf überholten Annahmen zu entscheiden – mit allen Konsequenzen. Teams, die regelmäßig bewusst für Klarheit sorgen, arbeiten schneller, wirksamer und mit weniger Reibungsverlusten. Dabei ist Klarheit oft unbequem. Sie verlangt, innezuhalten, nachzufragen und auch unangenehme Themen anzusprechen. Es kostet Mut und Energie, in Meetings Unsicherheiten offen zu machen, statt einfach weiterzugehen. Doch genau das zahlt sich aus: Was am Anfang Zeit kostet, spart später doppelte Arbeit und verhindert Missverständnisse. Klarheit braucht eine Kultur, in der Fragen ausdrücklich erwünscht sind und Unsicherheiten nicht als Schwäche gelten. Psychological Safety wird so zur Basis für echte Zusammenarbeit. Nur wenn Menschen sich sicher fühlen, auch unbequeme Wahrheiten auszusprechen, können Teams wirkliche Klarheit herstellen und aufrechterhalten. Im Gespräch wird auch deutlich, wie stark bewusste Sprache zur Klarheit beiträgt: Nicht vage bleiben, sondern präzise formulieren, nachfragen, visualisieren – so entsteht aus einem "Wir haben uns doch verstanden" eine belastbare Grundlage für Entscheidungen. Klarheit hilft, den Nebel frühzeitig zu lichten, bevor aus kleinen Missverständnissen große Probleme werden. Arne bringt es treffend auf den Punkt: Produktmenschen tragen die Verantwortung, Klarheit herzustellen – selbst wenn es unbequem wird. Gerade in cross-funktionalen Teams und in der Zusammenarbeit mit Stakeholdern macht das den entscheidenden Unterschied zwischen gut gemeinter Abstimmung und echter Wirksamkeit. Wer Klarheit über Komfort (siehe auch Matthew LeMay) stellt, schafft die Basis für nachhaltige Produktentwicklung – und stärkt nicht nur das eigene Team, sondern auch die eigene Wirksamkeit als Product Owner oder Produktmanager:in. Weitere Empfehlungen zum Vertiefen In dieser Podcastfolge sprechen wir auch über Themen, die wir in früheren Episoden vertieft haben. Wenn ihr tiefer eintauchen wollt, empfehlen wir euch diese Folgen: -POEM – Das Product Ownership Evolution Model -The Decision Stack – bessere Entscheidungen treffen -Ein Produkt einstellen – der Ramp Down von XING Events (mit Thomas Gläser) -Starke Produktmanager entwickeln (mit Petra Wille) Weitere Quellen Wir möchten euch insbesondere die Blog-Artikel von Arne zu den einzelnen Dimensionen von Klarheit empfehlen: Directional Clarity – Klarheit über die übergeordnete Richtung und Vision Situational Clarity – Klarheit über die aktuelle Situation und den nächsten sinnvollen Schritt Role Clarity – Klarheit über Rollen, Verantwortlichkeiten und Erwartungen im Team Clear Communication – klare, präzise und offene Kommunikation als Grundlage für Zusammenarbeit Clarity for Product Leaders – besondere Bedeutung von Klarheit in der Führungsverantwortung für Produktmenschen Wer mit Arne Kittler direkt in Kontakt treten möchte, erreicht ihn über seine Website (https://www.arnekittler.de/) oder sein LinkedIn-Profil. Folgt ihm auch gerne auf LinkedIn.

Viele Teams liefern solide Features, füllen regelmäßig ihr Sprint-Backlog und schaffen es, in kurzen Zyklen Output zu produzieren. Doch was am Ende häufig fehlt, ist die entscheidende Frage: Welche Wirkung hat das eigentlich beim Nutzer? Genau darum geht es in dieser Folge. Oliver und Tim nehmen sich die drei häufig vermischten Begriffe Output, Outcome und Impact vor und ordnen sie praxisnah ein – nicht als Buzzwords, sondern als Grundlage sinnvoller Produktarbeit. Output ist schnell sichtbar. Ein Release ist gemacht, ein Feature live. Doch das allein reicht nicht. Outcome meint die Veränderung, die daraus entsteht – idealerweise beim Nutzer. Ein Verhalten, das sich ändert. Eine Aufgabe, die leichter fällt. Ein Problem, das nicht mehr existiert. Und genau darum sollte es gehen: Wirkung vor Lieferung. Es ist diese Wirkung, der wir in der Produktentwicklung hinterherlaufen sollten – nicht nur dem fertigen Feature. Was das schwierig macht: Outcome ist oft nicht sofort greifbar. Er entsteht nicht exakt in dem Moment, in dem ein Button live geht oder ein Flow angepasst wird. Es braucht Beobachtung, echtes Nutzerverständnis, Hypothesen und die Bereitschaft, Wirkung als Lernfeld zu begreifen. Viele Teams bleiben beim Output stehen, weil er einfacher zu messen ist. Doch wer wirklich wissen will, ob ein Produkt erfolgreich ist, muss sich auf Outcome fokussieren – auch wenn das bedeutet, Unsicherheit auszuhalten. Gleichzeitig braucht es gute Grundlagen, denn ohne verlässlichen, qualitativ hochwertigen Output gibt es auch keinen Outcome. Doch die reine Lieferung darf nicht zum Selbstzweck werden. Es geht darum, das Produkt so weiterzuentwickeln, dass es tatsächlich etwas verändert – beim Menschen, der es nutzt, und letztlich auch beim Unternehmen, das es anbietet. Hier kommt der Impact ins Spiel. Denn wenn ein Feature genutzt wird, weil es einen echten Unterschied macht, dann kann daraus auch ein (positives) Geschäftsergebnis entstehen. Oliver und Tim zeigen in der Folge, wie Product Owner diese Perspektive einnehmen können – nicht als dogmatischen Rollenwechsel, sondern als bewussten Schritt. Outcome-orientiertes Arbeiten bedeutet, sich stärker mit Nutzerverhalten zu beschäftigen, Hypothesen zu formulieren, die Wirkung von Features zu hinterfragen und gemeinsam im Team zu reflektieren, was funktioniert – und was nicht. Es geht darum, sich vom Projektdenken zu lösen, Raum für Lernen zu schaffen und sich nicht nur an der Anzahl der ausgelieferten Features zu messen, sondern an der Veränderung, die sie bewirken. Outcome ist aber nicht immer eindeutig zuzuordnen. Manchmal braucht es Geduld, manchmal bleibt Wirkung aus, obwohl der Output gut war. Doch genau das ist der Kern moderner Produktentwicklung. Es geht nicht um Planbarkeit, sondern um Verantwortung für Wirkung. Und wer als Product Owner diese Wirkung gestalten will, kommt um den Outcome nicht herum. Erwähntes Video zur Erklärung der Begriffe: - The Mindset That Kills Product Thinking by Jeff Patton Frühere Folgen, auf die verwiesen wird: - Mit "Jobs to Be Done"-Interviews zum besseren Kundenverständnis - Finance Talk: Warum die Zahlen für deine Karriere wichtig sind - Agile Product Roadmaps - Nutze Story Mapping, um mit Stakeholdern über Outcome zu sprechen - Impact Mapping – was zahlt wirklich auf unser Business Ziel ein? - Outcome Goals & Product Discovery (Tim Herbig) Wie setzt du diese Begriffe ein? Wie erklärst du sie deinem Team und deinem Umfeld? Hast du weitere Tipps, um besser Outcome und Impact liefern zu können? Wir Produktwerker freuen uns, wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite.

Die Verantwortung als Product Owner:in ist nicht mehr das, was sie mal war – und genau darin liegt die Herausforderung, denn Veränderung passiert. Sie kommt schleichend, manchmal unbemerkt, manchmal mit Ansage. In jedem Fall aber erfordert sie Orientierung, Mut und die Bereitschaft, sich selbst zu hinterfragen. In dieser Folge sprechen Annette Greil, Maik Seyfert und Dominique über genau diesen Wandel – und darüber, wie man ihn aktiv gestalten kann. Die Veränderung betrifft dabei nicht nur Aufgaben, sondern das gesamte Selbstverständnis der Rolle. Während Product Owner:innen früher oft stark in der Delivery verankert waren, verschiebt sich der Schwerpunkt zunehmend in Richtung Discovery, Strategie und Business-Verantwortung. Das klingt erst einmal nach einem echten Upgrade. Doch mit der erweiterten Verantwortung kommen auch neue Erwartungen – und nicht selten Unsicherheit. Gerade wenn eine Organisation alte Strukturen aufbricht, entstehen Freiräume, die zwar viel Potenzial bieten, aber auch überfordern können. Denn: Nur weil man offiziell mehr entscheiden darf, heißt das nicht, dass man automatisch auch die Sicherheit hat, diese Entscheidungen zu treffen. Vergangenes Verhalten, kulturelle Prägung und gewachsene Erwartungen wirken oft lange nach. Viele Product Owner:innen müssen sich erst wieder zutrauen, wirklich agil zu arbeiten – gerade wenn sie aus stark regulierten oder hierarchischen Kontexten kommen. Was hilft, ist nicht nur methodisches Know-how, sondern auch ein Bewusstsein für die eigenen Stärken. Wer weiß, wie er tickt, kann besser mit Unsicherheit umgehen. Tools wie der Gallup Strengths Finder oder persönliche Reflexionsformate (vgl. dazu auch Sei dein eigenes Produkt) können hier wertvolle Unterstützung sein. Doch Veränderung lässt sich nicht allein stemmen. Die Verantwortung als Product Owner:in entwickelt sich in einem Umfeld weiter – und dieses Umfeld muss mitziehen. Teams, Stakeholder, Führungskräfte: Alle sind Teil des Veränderungsprozesses. Das bedeutet nicht nur neue Absprachen und Verantwortlichkeiten, sondern auch das Aushalten von Reibung. Widerstände gehören dazu – und sie sind oft kein Zeichen von Ablehnung, sondern Ausdruck von Unsicherheit. Was es braucht, ist Kommunikation auf Augenhöhe und die Bereitschaft, sich gemeinsam auf Neues einzulassen. Veränderung gelingt nicht durch starre Frameworks oder das bloße Umbenennen von Rollen. Sie braucht Begleitung, Reflexion – und vor allem Zeit. Workshops, Coachings, Community-Formate oder interne Netzwerke können dabei helfen, einen stabilen Rahmen zu schaffen, in dem Entwicklung möglich ist. Der wichtigste Rat von Annette und Maik: Ruhe bewahren. Nicht jede Veränderung ist sofort greifbar – aber sie ist eine Chance. Für persönliches Wachstum, für bessere Produkte und für eine stärkere Verbindung zwischen Technik, Business und Kund:innen. Am Ende ist es keine Frage, ob sich die Rolle des Product Owners verändert. Die Frage ist, wie wir damit umgehen. Wer neugierig bleibt, reflektiert und bereit ist, dazuzulernen, kann aus dem Wandel einen echten Entwicklungsschub machen. Für sich selbst – und für das ganze Produktteam.

Eine Zertifizierung ist für viele Product Owner ein Thema, das immer wieder aufkommt – oft dann, wenn sie neu in der Rolle sind oder sich weiterentwickeln wollen. Doch was bringt eine Zertifizierung wirklich? Ist sie nur ein Türöffner für den ersten Job oder hilft sie tatsächlich dabei, ein besserer Product Owner zu werden? Gleichzeitig gibt es eine Vielzahl an Anbietern für solche Zertifizierungen – von etablierten Organisationen wie der Scrum Alliance oder scrum.org bis hin zu eher unbekannten Anbietern. Jede Organisation verspricht einen eigenen Mehrwert. Manche Zertifikate lassen sich durch das Bestehen eines Online-Tests erwerben, andere setzen auf Trainings mit erfahrenen Coaches. Doch nicht jede Zertifizierung passt zu jedem Kontext oder Lerntyp. Eine Zertifizierung kann ein guter Einstieg sein, um sich strukturiert mit den Grundlagen des Product Ownership auseinanderzusetzen. Sie gibt Orientierung und zeigt, welche Themen zur Rolle gehören. Aber sie ersetzt nicht die tägliche Praxis, nicht den Austausch im Team, nicht die Auseinandersetzung mit Stakeholdern oder Nutzerbedürfnissen. Wer Product Owner ist, lernt ständig dazu – unabhängig vom Zertifikat auf dem Papier. Besonders spannend wird es, wenn wir uns die Motivation anschauen, warum Menschen überhaupt eine Zertifizierung machen wollen. Geht es um ein besseres Gehalt? Um Sichtbarkeit im Unternehmen? Oder darum, sich selbst sicherer in der Rolle zu fühlen? Je nach Zielsetzung können ganz unterschiedliche Formate sinnvoll sein. Für manche ist zum Beispiel ein Einstiegskurs wie der „Professional Scrum Product Owner“ (PSPO I) ideal, andere profitieren mehr von Advanced-Kursen mit Fokus auf Stakeholder-Management, strategischer Produktentwicklung oder Leadership. Zertifizierungen sind also weder gut noch schlecht – sie sind Werkzeuge. Und wie bei allen Werkzeugen kommt es darauf an, wie man sie einsetzt. Ein Product Owner, der gelernt hat, wie wichtig kontinuierliche Validierung von Hypothesen ist, wird sich nicht auf ein Zertifikat verlassen, sondern im Alltag ausprobieren, verwerfen, neu denken. Genau das macht die Rolle so anspruchsvoll – und so spannend. Am Ende zählt weniger, welches Logo auf dem Zertifikat steht, sondern was die Person daraus macht. Wer bereit ist, kontinuierlich zu lernen, Feedback anzunehmen und sich mit anderen POs zu vernetzen, braucht nicht unbedingt eine Zertifizierung, um gute Arbeit zu leisten. Aber sie kann ein sinnvoller Baustein sein – vor allem dann, wenn sie nicht als Endpunkt, sondern als Anfang verstanden wird.

Diesmal widmen wir uns dem User Experience Questionnaire (UEQ), einem bewährten Werkzeug zur Messung der UX. Bei uns zu Gast ist Andreas Hinderks, der an der Weiterentwicklung des UEQ mitarbeitet und besonders die Perspektive von Produktmenschen mit einbringt. Zur Zeit ist er Professor für Informatik, insbesondere Human Computer Interaction (HCI), an der Hochschule Hannover. Der UEQ ist ein wissenschaftlich fundierter Fragebogen, der verschiedene Dimensionen der UX misst, darunter Attraktivität, Effizienz, Steuerbarkeit, Stimulation und Originalität. In der Praxis ermöglicht der UEQ eine schnelle und fundierte Einschätzung der User Experience. Anstatt sich auf subjektive Einzelmeinungen zu verlassen, erhalten Unternehmen messbare Daten, die klare Hinweise auf Stärken und Schwächen ihres Produkts liefern. Gerade für Product Owner ist dies ein entscheidender Vorteil, da sie datenbasierte Entscheidungen treffen können, um die Nutzerfreundlichkeit gezielt zu optimieren. Im Gespräch diskutieren Dominique und Andreas, wie der UEQ in verschiedenen Kontexten angewendet werden kann. Besonders in agilen Entwicklungsprozessen bietet sich der Fragebogen an, um nach jedem Sprint oder größeren Produkt-Iterationen die UX-Qualität systematisch zu überprüfen. So lässt sich nachvollziehen, ob Anpassungen tatsächlich eine Verbesserung der Nutzererfahrung bewirken. Der UEQ hilft dabei, die subjektiven Eindrücke der Nutzer in eine objektive, vergleichbare Form zu bringen. Ein großer Vorteil des UEQ ist die Möglichkeit, Ergebnisse mit Benchmark-Daten zu vergleichen. Da der Fragebogen in vielen Branchen eingesetzt wird, können Unternehmen ihre Werte mit bestehenden Datensätzen abgleichen und so erkennen, wo ihr Produkt im Wettbewerbsumfeld steht. Natürlich bringt der Einsatz des UEQ auch Herausforderungen mit sich. Die Qualität der Ergebnisse hängt stark davon ab, wie sorgfältig die Befragung durchgeführt wird. Teilnehmer sollten den Fragebogen ehrlich und aufmerksam ausfüllen, um aussagekräftige Daten zu erhalten. Zudem sollten die Ergebnisse nicht isoliert betrachtet werden, sondern stets im Kontext der Produktstrategie und Nutzerbedürfnisse. Zum Abschluss der Folge gibt Andreas praxisnahe Tipps, wie sich der UEQ optimal in den Arbeitsalltag integrieren lässt. Wer sich mit UX-Messung beschäftigt oder eine datenbasierte Entscheidungsgrundlage für die Weiterentwicklung seines Produkts sucht, findet in dieser Episode wertvolle Impulse. Der UEQ bietet einen pragmatischen Ansatz, um UX greifbar zu machen und nachhaltige Produktverbesserungen zu erzielen. Wenn ihr mehr zum UEQ wissen wollt, schaut gern mal unter www.ueq-online.org. Dort bekommt ihr den Fragebogen in allen Sprachversionen aber auch Auswertungshilfen, die ihr kostenfrei nutzen könnt. Außerdem war Andreas schon mal mit dem Thema UX-Management zu Gast. Auch eine Folge, die wir sehr empfehlen können.

Produktqualität ist ein Thema, das Product Owner immer wieder vor Herausforderungen stellt. In der neuesten Episode der Produktwerker sprechen Oliver und Dominique darüber, wie Product Owner das Bewusstsein für Qualität im gesamten Team stärken können. Denn schlechte Produktqualität kann nicht nur die Nutzererfahrung negativ beeinflussen, sondern auch den Arbeitsfluss des Teams stören und langfristig viele negative Folgen verursachen. Die Verantwortung für die Produktqualität wird in vielen agilen Produktteams unterschiedlich wahrgenommen. Während Entwickler häufig die technische Qualität in den Fokus stellen, müssen Product Owner sicherstellen, dass das Produkt nicht nur funktional, sondern auch nutzerzentriert und nachhaltig entwickelt wird. Hier entsteht schnell ein Spannungsfeld zwischen Geschwindigkeit und Sorgfalt. Oliver und Dominique sind sich einig: Qualität, egal über welche Perspektive man spricht, ist nicht verhandelbar. In einem iterativen Entwicklungsprozess muss Qualität von Anfang an mitgedacht und konsequent umgesetzt werden, damit ein stabiles, erweiterbares und zukunftsfähiges Produkt entsteht. Auf der einen Seite ist die äußere Produktqualität wichtig, also wie Nutzer das Produkt erleben. Um sicherzustellen, dass ein Produkt einen Beitrag zur Problemlösung leisten kann, ist es wichtig, die Erwartungshaltung von Nutzern genau zu kennen und Metriken zur Messung der Nutzererfahrung zu etablieren. Product Owner können Qualität in den Fokus rücken, indem sie diese Metriken nicht nur bei der Entwicklung neuer Features berücksichtigen, sondern auch in Reviews und strategische Entscheidungen mit einfließen lassen. Ebenso bedeutend ist die innere Qualität, also die technische Exzellenz des Produkts. Ein schlecht strukturierter Code kann langfristig zu Problemen führen, die die Entwicklung verlangsamen und Innovationen erschweren. Daher ist es wichtig, dass Product Owner Raum für technische Verbesserungen und nachhaltige Entwicklungspraktiken wie automatisierte Tests oder Refactoring schaffen. Hier sollten sie mit Entwicklern und dem Scrum Master offen diskutieren, wie viel Zeit für technische Qualität eingeplant wird, um langfristig effizient zu bleiben. Ein weiterer Faktor ist die Zusammenarbeit im Team. Qualität entsteht nicht nur durch technisches Können, sondern auch durch gute Kommunikation, klare Verantwortlichkeiten und Vertrauen. Product Owner sollten in Retrospektiven gezielt das Thema Produktqualität ansprechen und gemeinsam mit dem Team reflektieren, welche Maßnahmen Qualität langfristig sichern können. Auch psychologische Sicherheit spielt eine Rolle: Teammitglieder müssen sich trauen, Probleme offen anzusprechen, um Verbesserungen anzustoßen. Ein starkes Qualitätsbewusstsein entsteht nicht von heute auf morgen. Es erfordert kontinuierliche Aufmerksamkeit, einen gemeinsamen Anspruch an Exzellenz und eine Kultur der Zusammenarbeit. Product Owner haben dabei die Aufgabe, das Thema Qualität immer wieder ins Bewusstsein zu rufen und durch ihr eigenes Verhalten vorzuleben. Denn nur so kann langfristig ein Produkt entstehen, das sowohl technisch robust als auch für Nutzer wertvoll ist.

Diesmal geht es um ein Thema, das in der Produktentwicklung oft zu kurz kommt: Well-Being. Während Produktverantwortliche intensiv daran arbeiten, ihre Software effizienter, benutzerfreundlicher und funktionaler zu gestalten, bleibt eine zentrale Frage häufig unbeachtet: Wie beeinflussen digitale Produkte das langfristige Wohlbefinden ihrer Nutzerinnen und Nutzer? Zu Gast ist Tim-Can Werning, Wirtschaftspsychologe und Forscher zum Thema Wohlbefinden im Kontext von Technologie. Er beschreibt, wie Produkte nicht nur kurzfristig nützlich, sondern auch langfristig förderlich für das subjektive Wohlbefinden sein können. Dabei verweist er auf das Konzept des Subjective Well-Being, das neben allgemeiner Lebenszufriedenheit auch die domänenspezifische Zufriedenheit umfasst. Gerade Letzteres ist spannend für Produktverantwortliche, denn viele Menschen nutzen Software nicht freiwillig, sondern als Teil ihres Arbeitsalltags. Die Auswirkungen auf ihre Zufriedenheit gehen daher über den Arbeitsplatz hinaus. Ein Schlüsselkonzept in der Psychologie, das für die Produktgestaltung relevant ist, ist die Selbstbestimmungstheorie. Sie benennt drei grundlegende psychologische Bedürfnisse: Autonomie, Kompetenzerleben und soziale Eingebundenheit. Diese Faktoren beeinflussen, wie motiviert und zufrieden Menschen mit einer Tätigkeit oder einem digitalen Produkt sind. Ein Beispiel aus dem Gespräch zeigt, wie eine Sportuhr durch ihre Art des Feedbacks dem Nutzenden entweder ein Erfolgserlebnis verschaffen oder ihm das Gefühl von Unzulänglichkeit vermitteln kann. Eine unüberlegte Gestaltung kann so das Wohlbefinden ungewollt negativ beeinflussen. Langfristigkeit in der Produktentwicklung ist ein spannendes Thema. Oft wird Erfolg an kurzfristigen KPIs gemessen. Doch was passiert, wenn Nutzer:innen ein Produkt über Monate oder Jahre hinweg verwenden? Welche langfristigen Auswirkungen hat es auf ihr Wohlbefinden? Ein positives Beispiel liefert das Computerspiel Anno 1800, das nach einer gewissen Spielzeit Pausen vorschlägt, um exzessives Spielen zu vermeiden und das Wohlbefinden der Nutzer:innen zu schützen. Hier zeigt sich, dass bewusste Produktgestaltung weit über kurzfristige Interaktionen hinausgeht. Das Well-Being sollte also als integraler Bestandteil der Produktentwicklung gesehen werden. Denn am Ende profitieren nicht nur die Nutzer:innen von besser durchdachten Produkten, sondern auch Unternehmen, deren Software langfristig als positiv wahrgenommen wird.

Im Alltag begegnen uns unzählige Produkte und Services – einige begeistern uns, andere sorgen für Frust. Doch was können Product Owner aus solchen Produkterlebnissen lernen? In dieser Folge der Produktwerker sprechen Oliver und Tim genau darüber: Wie lassen sich alltägliche Produkterlebnisse nutzen, um die eigene Produktentwicklung zu verbessern? Tim berichtet von einem Getränkekiosk, in dem er glutenfreies Bier nachfragte. Der Besitzer hatte es nicht im Sortiment, zeigte aber großes Interesse und entschied spontan, eine Testbestellung aufzugeben. Ein Beispiel dafür, wie experimentelles Vorgehen und direkte Kundenrückmeldungen Unsicherheiten reduzieren können. Wer sein Produkt verbessern will, sollte solche Produkterlebnisse aktiv suchen und aus ihnen lernen. Ein anderes Erlebnis zeigt, wie schnell schlechte Usability negative Emotionen hervorrufen kann. Im Skiurlaub wurde Tim bei einer Skileihe nach langem Warte abgewiesen, da er sich nicht im voraus an einem Terminal mit seinen Daten registriert hatte. Die fehlende Kommunikation darüber frustrierte ihn. Ein weit verbreitetes Problem: Unternehmen als auch Product Owner betrachten oft nur einzelne Prozessschritte, statt das gesamte Nutzererlebnis zu optimieren. Aber Oliver und Tim finden auch positive Beispiele: Nach einem Skiunfall erhielt Tim nach seinem MRT sofort einen QR-Code, mit dem er die Bilder digital abrufen konnte. Eine kleine Änderung, die für mehr Transparenz sorgt und den Nutzern Eigenverantwortung ermöglicht. Es gibt eine ganze Reihe von Kontexten, in denen Produkterlebnisse, die Autonomie fördern, einen bleibenden positiven Eindruck hinterlassen. Ähnliche Erfahrungen machte Oliver im öffentlichen Nahverkehr. In Österreich nutzte er eine App, die den Ticketkauf stark vereinfachte. Kein Tarifzonen-Wirrwarr, kein umständliches Bezahlen – einfach einsteigen, aussteigen, fertig. Ein Paradebeispiel für das Lösen eines Nutzerproblems, welches gleichzeitig noch Komplexität reduziert. Doch längst nicht alle digitalen Services funktionieren so reibungslos. In einem Berliner Museum buchte Tim zeitgebundene Tickets, um lange Wartezeiten zu vermeiden – nur um dann festzustellen, dass das System völlig überlastet oder die Zeiten total überbucht waren und sich der Einlass um Stunden verschoben hatte. Ein klassisches Beispiel für falsches Erwartungsmanagement, das letztlich zu Frustration beim Nutzer führt. Diese sehr persönlichen und auch viele weitere Geschichten zeigen, wie sehr Produkterlebnisse unseren Blick auf Produktentwicklung schärfen können. Wer als Product Owner mit offenen Augen durch den Alltag geht, erkennt Muster, findet Inspiration und kann aus realen Erfahrungen wertvolle Erkenntnisse für die eigene Arbeit ziehen. Daher unsere Einladung: Reflektiert eure eigenen Produkterlebnisse und überlegt, welche Prinzipien ihr auf eure Produkte übertragen könnt. Welche Erfahrungen hast du aus der Nutzung anderer Produkten für dein eigenes Produkt ableiten können? Gibt es ein Produkterlebnisse, die dich so nachhaltig begeistert haben, dass du etwas adaptiert oder kopiert hast? 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.

Zeitmanagement – ein Dauerthema für Product Owner und Produktmanager. In der aktuellen Folge der Produktwerker spricht Tim mit Jennifer Michelmann über die endlose Jagd nach mehr Zeit und warum herkömmliche Zeitmanagement-Methoden oft nicht die Lösung sind. Jennifer hat viele Jahre Erfahrung im Produktmanagement und kennt den permanenten Druck, ständig verfügbar und ansprechbar zu sein. Aber sie hat auch gelernt, wie man sich daraus befreit. Ihr Ansatz: Statt sich in Methoden und To-do-Listen zu verlieren, geht es darum, die eigene Rolle und Erwartungen zu hinterfragen. Eines der größten Probleme ist die Selbstverständlichkeit, mit der Überlastung akzeptiert wird. Product Owner erzählen sich gegenseitig, wie viele Meetings sie haben und wie wenig Zeit für die wirklich wichtigen Dinge bleibt – bis daraus eine ungeschriebene Regel wird: Wer nicht gestresst ist, macht etwas falsch. Doch genau hier setzt Jennifer an. Sie fordert dazu auf, bewusste Entscheidungen zu treffen und sich von dem Gedanken zu lösen, immer für alles zuständig zu sein. Mit ihrem "Stop DANCE"-Prinzip zeigt sie einen Weg aus der Überforderung: Define Priorities, Allocate Time, Notice Patterns, Colleagues & Establish Boundaries. Die Idee dahinter? Klar definieren, was wirklich zählt, gezielt Zeit reservieren, eigene Muster erkennen, Unwichtiges bewusst weglassen und klare Grenzen setzen. Wer diese Prinzipien ernst nimmt, gewinnt nicht nur mehr Zeit, sondern auch mehr Klarheit in seiner Rolle. Meetings sind ein weiteres großes Thema: Sind wirklich alle Termine notwendig? Ein radikaler Schritt kann sein, alle Serientermine zu löschen und zu beobachten, was davon tatsächlich wieder im Kalender landet. Auch die Art der Zusammenarbeit mit Stakeholdern sollte überdacht werden – nicht jede Abstimmung muss synchron erfolgen. Besonders spannend ist die Frage, wie Product Owner mit ihren Führungskräften umgehen. Jennifer rät dazu, die eigene Arbeit sichtbarer zu machen, Erwartungen aktiv zu managen und klar zu kommunizieren, was realistisch machbar ist. Wer auf Entscheidungen wartet, wartet oft vergeblich – und sollte deshalb lieber selbst mutige Prioritäten setzen. Und dann ist da noch das Thema Stress. Jennifer warnt vor dem gefährlichen Kreislauf des permanenten Funktionierens. Wer nur noch reagiert, verliert die Kontrolle. Ihr Rat: Regelmäßig innehalten, bewusst reflektieren und erkennen, wann strukturelle Veränderungen notwendig sind. In manchen Fällen kann das sogar bedeuten, den Job zu wechseln. Zeitmanagement ist keine Frage der Technik, sondern der Haltung. Wer es schafft, klare Grenzen zu setzen, sich nicht in Meetings und operativen Details zu verlieren und bewusst Verantwortung zu übernehmen, gewinnt nicht nur wertvolle Zeit zurück – sondern auch mehr Zufriedenheit im Job. Frühere Episoden, die im Gespräch erwähnt wurden: - Keine Zeit haben als Product Owner - Introvertiert als Product Owner - geht das? Wenn euch mehr guter Content von Jennifer Michelmann interessiert, empfehlen wir folgende Links: - Talk von Jennifer bei der Product at Heart 2024: "How to take care of a limited resource and become a better PM" - Passender Blog-Artikel von Jennifer: "Time management for product managers" - Weitere Artikel von Jennifer in ihrem Blog auf Medium: jennifer-michelmann.medium.com Eine explizite Literatur-Empfehlung von Jennifer Michelmann zum Thema: - Elisabeth Ayer: "Don’t ask forgiveness, radiate intent" Wer mit Jennifer Michelmann direkt in Kontakt trete möchtest, erreichst sie am Besten über ihr LinkedIn-Profil. Wir hoffen, dass du einige neue Impulse aus den Gespräch mit Jennifer gewinnen konntest. Wie gehst du dein Zeitmanagement an? Hast du vielleicht spezielle Tipps? Vielleicht magst du etwas darüber berichten? 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 macht großartige Product Owner wirklich aus? Diese Frage wird oft mit Methoden, Tools oder Prozessen beantwortet. Doch im Kern ist es die Product Owner Haltung, die den entscheidenden Unterschied macht. In dieser Folge der Produktwerker reflektieren Dominique und Oliver, welche Haltungen erfolgreiche Product Owner prägen – und warum sie oft über Erfolg oder Misserfolg entscheiden. Eine wichtige Fähigkeit ist Entscheidungen zu treffen. Product Owner stehen ständig vor der Herausforderung, unter Unsicherheit abzuwägen und dennoch handlungsfähig zu bleiben. Es geht nicht nur darum, mutig zu sein, sondern auch die Balance zwischen Informationstiefe und Handlungsfähigkeit zu finden. Eine Entscheidung zu vertagen ist oft selbst eine Entscheidung – und nicht immer die beste. Doch Entscheidungskompetenz allein reicht nicht. Großartige Product Owner sind auch generell exzellente Kommunikatoren. Sie müssen Informationen aufnehmen, vermitteln und den Dialog mit Stakeholdern aktiv gestalten. Diese Fähigkeit ist eng mit Empathie verknüpft: Wer die Bedürfnisse von Nutzer:innen, Entwickler:innen und Business-Stakeholdern gleichermaßen versteht, kann fundierte Priorisierungen treffen und tragfähige Kompromisse finden. Ein weiterer Aspekt der Product Owner Haltung ist die unternehmerische Denkweise. Wertmaximierung steht im Fokus – aber nicht um jeden Preis. Nachhaltigkeit spielt eine entscheidende Rolle: Ein kurzfristiger Erfolg, der langfristige Produktentwicklung behindert, ist keine echte Wertsteigerung. Technische Schulden oder ein überlastetes Team können auf lange Sicht den Produktfortschritt ausbremsen. Letztlich zeigt sich eine starke Product Owner Haltung darin, flexibel und situationsangepasst zu handeln. Ein Product Owner muss je nach Kontext verschiedene Führungsstile anwenden, von coachendem Enablement bis hin zu klaren strategischen Vorgaben. Diese Vielseitigkeit ermöglicht es, unterschiedliche Herausforderungen souverän zu meistern.

Finanzen sind trocken? Von wegen! In der neuesten Folge der Produktwerker geht es um ein Thema, das für Product Owner oft unter dem Radar bleibt, aber entscheidend für ihre Karriere ist: Finanzwissen. Tim spricht mit Simonetta Batteiger, einer erfahrenen Product Leadership Coachin, über die Relevanz von Zahlen im Produktmanagement und Finanzwissen für Product Owner. Warum sollten sich Product Owner mit Finanzwissen beschäftigen? Viele verstehen intuitiv, wie wichtig Nutzerzentrierung ist, doch die wirtschaftliche Perspektive eines Produkts wird oft vernachlässigt. Simonetta, die selbst eine Karriere im Finance-Bereich startete, bevor sie ins Produktmanagement wechselte, macht deutlich: Wer als Product Owner langfristig erfolgreich sein will, sollte die Zahlen verstehen. Umsatz, Kosten, Marge – diese Faktoren bestimmen nicht nur den Erfolg eines Produkts, sondern auch den eigenen Karriereweg. Product Owner stehen häufig vor der Herausforderung, den Mehrwert ihrer Arbeit für das Unternehmen greifbar zu machen. Ein gut durchdachter Business Case kann hier den entscheidenden Unterschied machen. Wer zeigen kann, wie Produktentscheidungen den Umsatz steigern oder Kosten optimieren, verschafft sich Gehör bei Stakeholdern und Führungsebenen. Gerade in Zeiten wirtschaftlicher Unsicherheit wird das Finanzwissen für Product Owner immer relevanter. Simonetta betont, dass es kein Hexenwerk ist, sich dieses Wissen anzueignen. Ein guter erster Schritt ist der Austausch mit dem Finanzteam: Welche Metriken sind im Unternehmen wirklich relevant? Auf welche KPIs achtet die Geschäftsleitung? Wer diese Fragen stellt, zeigt Initiative und stärkt seine Position als strategische Gestalterin seines Produkts. Auch das Thema Budgetierung kommt im Gespräch auf. Viele Product Owner empfinden den id.R. jährlichen Budgetierungsprozess als Hürde, doch wer ihn versteht, kann ihn aktiv nutzen. Die Budgetplanung ist die beste Gelegenheit, um sich notwendige Ressourcen für das nächste Jahr zu sichern – sei es für neue Teammitglieder, Weiterbildungen oder technische Infrastruktur. Wer Finanzwissen in die eigene Arbeit integriert, trifft nicht nur fundiertere Entscheidungen, sondern stärkt auch seine Rolle im Unternehmen. Ein weiterer wichtiger Punkt: Finanzwissen hilft dabei, mit anderen Abteilungen auf Augenhöhe zu sprechen. Ob mit dem Finanzteam, der Geschäftsführung oder dem Sales-Bereich – wer ihre Sprache spricht und mit Zahlen argumentieren kann, wird ernster genommen und kann seine Roadmap selbstbewusster verteidigen. Ein Product Owner, der Finanzwissen mitbringt, ist weniger austauschbar und steigert seine Karrierechancen erheblich. Wer sich weiterbilden möchte, findet zahlreiche Ressourcen, von Online-Kursen bis hin zu internen Trainings. Simonetta bietet selbst eine regelmäßige Kursreihe für eine kleine Kohorte an, die speziell für Produktmenschen entwickelt wurden. Ihr abschließender Rat: Einfach mal das Gespräch mit dem Finanzteam suchen und neugierig sein. Finanzwissen für Product Owner ist kein Nice-to-have, sondern ein echter Karriere-Booster. Kontakt zu Simonetta Batteiger nehmt ihr am Besten über ihre LinkedIn-Seite auf. Weiterführende Links: - Infos & Buchung zum angesprochenen Kurs von Simonetta: Business and Finance - Concepts for Product and Tech Leaders - Post von Simonetta aus Mind the Product: Finance skills for product people - Blogpost Simonetta Batteiger: So you want a high performing product team? - Blogpost Simonetta Batteiger: How to think and talk about business impact Diese früheren Podcast-Folgen wurden erwähnt: - Leadership Skills für Produktmenschen (Gast. Simonetta Batteiger) - Business KPIs die Product Owner kennen sollten - Produktmanager in einem Startup - Erfahrungsbericht eines Buchhalters

Als Product Owner ist es essenziell, sich kontinuierlich weiterzuentwickeln und die richtigen Werkzeuge für die tägliche Arbeit zu nutzen. In der neuesten Episode der Produktwerker geht es genau darum: Welche Methoden für Product Owner sind wirklich relevant? Eine der wichtigsten Grundlagen ist die Produktvision. Hier hilft das Product Vision Canvas bzw. das Product Vision Board (von Roman Pichler), um ein gemeinsames Verständnis im Team und mit Stakeholdern zu schaffen. Ob mit dem Framework von Roman Pichler oder dem Positioning Statement von Geoffrey Moore – entscheidend ist, dass die Produktvision klar und lebendig bleibt. Eng verknüpft mit der Produktvision ist das Thema Roadmapping. Klassische, feature-getriebene Roadmaps sind längst überholt. Stattdessen setzen erfahrene Product Owner auf Outcome-orientierte Roadmaps, etwa in Form der Now-Next-Later-Roadmap. Dabei geht es nicht darum, starre Zeitpläne einzuhalten, sondern den Fokus auf die gewünschten Wirkungen zu legen. Für eine sinnvolle Planung ist außerdem Story Mapping unverzichtbar. Diese Methode hilft, eine holistische Sicht auf das Produkt zu behalten, Features sinnvoll zu priorisieren und das Team in die richtige Richtung zu steuern. Jeff Patton hat mit dem User Story Mapping eine Praxis entwickelt, die das Verständnis für Wirkungsschnitte und Priorisierung stärkt. Ein weiteres wertvolles Tool im Werkzeugkasten eines Product Owners ist der Opportunity Solution Tree (OST), bekannt aus Teresa Torres’ Buch Continuous Discovery Habits. Der OST ermöglicht es, Business-Ziele mit Kundenbedürfnissen zu verknüpfen und den besten Weg zur Lösung abzuleiten. Etwas älter, aber genauso wirksam ist das Impact Mapping von Gojko Adzic – ein strukturierter Ansatz, um zu visualisieren, welche Akteure ihr Verhalten ändern müssen, damit das Produkt erfolgreich wird. In der täglichen Arbeit von Product Ownern spielen Annahmen eine große Rolle. Doch oft sind diese weder hinterfragt noch belegt. Hier kommt das Assumption Mapping ins Spiel. Mit dieser Methode von David J. Bland lassen sich Annahmen systematisch priorisieren und durch gezielte Experimente validieren. Auch das Arbeiten mit User-Feedback gehört zu den essenziellen Methoden für Product Owner. Hier hilft der Interview-Snapshot aus Teresa Torres’ Discovery-Ansatz, um strukturierte Erkenntnisse aus Nutzerinterviews zu ziehen. In Kombination mit dem Value Proposition Canvas von Alexander Osterwalder lassen sich die relevanten Pain Points und Gains der Nutzer noch klarer herausarbeiten. Natürlich darf auch das Thema User Stories nicht fehlen. Diese Technik ermöglicht eine nutzerzentrierte Formulierung von Anforderungen. Doch User Stories sind nur so gut wie ihre Akzeptanzkriterien und die Fähigkeit, sie sinnvoll zu schneiden. Deshalb ist es entscheidend, nicht nur das Schreiben, sondern auch das Splitting von User Stories zu beherrschen. Ein weiterer Bereich, der oft unterschätzt wird, ist das Stakeholder-Management. Ohne eine gezielte Strategie kann die Vielzahl an Stakeholdern schnell zur Herausforderung werden. Das Power-Interest-Grid hilft dabei, die richtigen Prioritäten zu setzen und Stakeholder effektiv einzubinden. Daneben sehen wir noch eine elfte Methode, quasi als "Bonus-Thema", das in den letzten Jahren immer wichtiger wird: AI-Prompting. Die Fähigkeit, mit Tools wie ChatGPT oder Perplexity effizient zu arbeiten, kann für Product Owner einen enormen Vorteil bringen – sei es für die Generierung von Ideen, die Analyse von Feedback oder die Strukturierung von Informationen. AI wird zunehmend zum Wingman für Product Owner und sollte daher als fester Bestandteil des Methodensets verstanden werden. Diese zehn Methoden für Product Owner sind nicht nur theoretische Konzepte, sondern praxisbewährte Werkzeuge, die den Alltag eines POs erleichtern und das Produktmanagement auf ein neues Level heben. Welche dieser Methoden setzt du bereits ein? Und welche fehlt deiner Meinung nach in dieser Liste?

Die Granularität, oder auch Kleinteiligkeit, von Product Backlog Items ist eine ständige Herausforderung für Product Owner. Manchmal sind die Product Backlog Items zu groß oder man leider unter viel zusätzlicher Verwaltungsarbeit, weil immer wieder ganze Pakete an kleinteiligen Items repriorisiert werden müssen. Das zentrale Thema der Folge ist also die Größe eines Backlog Items. Während der Scrum Guide lediglich fordert, dass Einträge innerhalb eines Sprints abgeschlossen sein sollten, empfehlen Dominique und Oliver eine zusätzliche Regel: Ein Item sollte nicht mehr als die Hälfte des Sprints in Anspruch nehmen. Diese Daumenregel hilft dabei, das Risiko zu minimieren, dass sich ein einzelnes Item über den gesamten Sprint zieht und zu wenig Spielraum für Anpassungen bleibt. Doch Granularität ist nicht nur eine Frage der Planung, sondern auch der langfristigen Produktstrategie. Items, die erst in ferner Zukunft relevant sind, können zunächst grob formuliert sein. Je näher der Umsetzungstermin rückt, desto feiner werden sie definiert. Oliver betont, dass eine zu frühe Detailierung oft überflüssig ist, weil sich Prioritäten im Laufe der Zeit ändern. Das Zusammenfassen und Neuformulieren von Items kann deshalb ebenso sinnvoll sein wie das Zerteilen größerer Einträge. Ein weiteres Thema ist die Handhabung von Granularität im Sprint. Unterschiedlich große Items innerhalb eines Sprints sind kein Problem, solange sie alle einen Mehrwert liefern und das Team die Zusammenhänge versteht. Eine gesunde Mischung aus kleinen, mittleren und größeren Items kann sogar dabei helfen, besser zu lernen und das Forecasting zu verbessern. Ein rein auf gleich große Einträge ausgerichtetes Backlog – wie es beim No Estimates-Ansatz oft gefordert wird – kann zwar die Vorhersagbarkeit erhöhen, schränkt aber unter Umständen die Flexibilität ein. Die Diskussion zeigt, dass Product Owner die Granularität ihrer Backlog Items bewusst steuern sollten. Refinement-Aktivitäten sind notwendig, um sicherzustellen, dass ein gemeinsames Verständnis im Team herrscht. Dabei ist jedoch auch Mut zur Lücke gefragt: Nicht jedes Item muss bis ins kleinste Detail ausformuliert werden. Gerade bei sehr kleinen Verbesserungen kann es sinnvoller sein, sie direkt umzusetzen, anstatt sie ins Backlog aufzunehmen. Letztlich ist die optimale Granularität immer vom jeweiligen Produkt und Team abhängig. Product Owner sollten sich bewusst machen, dass sie nicht nur für den Inhalt des Backlogs verantwortlich sind, sondern auch für seine Struktur und Handhabbarkeit.

In dieser Folge des Produktwerker Podcast diskutieren Oliver und sein Gast Urs Reupke über das Zusammenspiel von OKRs und Scrum. Urs, Unternehmensberater bei it-agile und Certified Scrum Trainer der Scrum Alliance, teilt seine Einblicke in die praktische Anwendung von OKRs und erklärt, wie diese Methode der Zielsetzung und Fortschrittsmessung die agile Produktentwicklung bereichern kann. OKRs, also “Objectives and Key Results”, dienen dazu, klare Ziele zu definieren und den Fortschritt durch messbare Ergebnisse zu überprüfen. Diese Struktur passt sehr gut zur iterativen Natur von Scrum. Insbesondere das Prinzip von Inspect und Adapt, das in Scrum fest verankert ist, findet auf einer höheren Ebene in OKRs seine Entsprechung. Während die Produktvision in Scrum oft schwer operationalisierbar scheint, können OKRs als Brücke dienen, um große strategische Ziele in umsetzbare Zwischenschritte zu übersetzen. Eine zentrale Erkenntnis aus der Diskussion von Urs und Oliver ist, dass OKRs Product Ownern helfen können, sich auf Outcome-Ziele zu konzentrieren, anstatt sich ausschließlich auf Outputs zu fixieren. Diese Fokussierung auf Wirkung eröffnet Product Ownern und ihren Teams mehr Freiräume, eigenverantwortlich Entscheidungen zu treffen und kreative Lösungen zu finden. Die Verbindung von OKRs und Scrum ermöglicht es, strategische Ziele nicht nur zu definieren, sondern auch mit konkreten Aktionen im Sprint voranzutreiben.. Ein weiterer Vorteil von OKRs in der agilen Produktentwicklung liegt in der Möglichkeit, den Diskurs mit Stakeholdern auf eine strategische Ebene zu heben. Anstatt über einzelne Features zu debattieren, können sich Gespräche auf die gewünschte Wirkung und übergeordnete Ziele konzentrieren. Dies kann Product Owner entlasten und gibt ihnen die Freiheit, die Umsetzung eigenständig zu gestalten, ohne dass Stakeholder in die Details eingreifen. Die Folge endet mit Urs’ praktischer Empfehlung an alle Product Owner: Einfach anfangen! Auch ohne die gesamte Organisation von OKRs zu überzeugen, können Teams die Methode für sich ausprobieren, um Fokus und Klarheit zu gewinnen.

Cost of Delay, auf Deutsch Verzögerungskosten, beschreibt die wirtschaftlichen Verluste, die entstehen, wenn ein Produkt oder Feature später als geplant auf den Markt kommt. In der neuen Folge von der Produktwerker diskutieren Tim und Dominique, warum dieses Konzept für Product Owner zentral ist und wie es uns bei strategischen Entscheidungen helfen kann. Dominique definiert Cost of Delay als die Summe aller wirtschaftlichen Kosten, die durch Verzögerungen entstehen. Das reicht von entgangenen Umsätzen und Marktanteilen bis hin zu Lizenz- oder Wartungskosten für alte Systeme. Ein Beispiel zeigt, wie ein verspäteter Systemwechsel zu Millionen Euro zusätzlichen Lizenzgebühren führen kann. Aber auch weiche Faktoren wie verlorene Marktreputation oder Kundenzufriedenheit können in die Bewertung einfließen. Besonders praktisch wird Cost of Delay bei der Priorisierung von Backlog-Items. Features können wie verderbliche Waren betrachtet werden: Je später sie geliefert werden, desto geringer ihr Nutzen. Um das zu quantifizieren, benötigt man eine klare Formel. Ein gängiger Ansatz ist, die Kosten pro Zeiteinheit zu berechnen, zum Beispiel pro Woche oder Sprint, und diese durch die Größe der Arbeit zu teilen. Dieser Ansatz ähnelt dem Konzept Weighted Shortest Job First (WSJF). In der Praxis ist jedoch nicht immer alles messbar. Dominique und Tim betonen, dass Schätzungen oft auf Annahmen basieren müssen. Dabei geht es nicht um absolute Genauigkeit, sondern um eine Diskussion, die ein gemeinsames Verständnis schafft. „Es ist besser, mit unscharfen Daten zu arbeiten, als gar keine Grundlage zu haben“, so Dominique. Wichtig sei es, Annahmen zu dokumentieren und regelmäßig zu überprüfen. Darübe rhinaus ist ein weiterer spannender Aspekt die enge Verbindung zwischen Cost of Delay und der Produktstrategie. Unternehmen müssen abwägen, ob sie lieber schnell liefern oder auf Perfektion setzen wollen. Diese Entscheidung hat nicht nur Einfluss auf die Priorisierung einzelner Aufgaben, sondern auch auf die langfristige Marktpositionierung. Die Folge schließt mit wertvollen Tipps für den Einstieg in das Thema Cost of Delay. Tim und Dominique raten dazu, sich zunächst auf einfache Annahmen zu stützen und diese regelmäßig zu überprüfen. Denn nur wer die Kosten von Verzögerungen versteht, kann nachhaltig erfolgreiche Produkte entwickeln. Passend zur aktuellen Folge empfehlen wir euch übrigens noch diese Folge, weil sie thematisch sehr passen und in der Folge referenziert werden: - Technische Schulden und wie wir als Product Owner damit umgehen (https://produktwerker.de/technische-schulden/) - Flow Metriken für Scrum Product Owner (https://produktwerker.de/flow-metriken/) - Product Principles (https://produktwerker.de/product-principles/) - Produktstrategie in die Praxis bringen (https://produktwerker.de/produktstrategie-in-die-praxis-bringen/)

In dieser Folge der Produktwerker geht es darum, wie Product Roadmaps in der täglichen Arbeit eingesetzt werden können. Zu Beginn eines Jahres investieren viele Product Owner und Produktmanager viel Energie in die Erstellung einer Product Roadmap. Doch was passiert danach? Die Roadmap, die oft als Ergebnis intensiver Diskussionen und strategischer Planung entsteht, ist kein statisches Dokument, sondern ein dynamisches Werkzeug, das den Alltag von Produktteams prägen sollte. Eine Product Roadmap gibt die Richtung vor. Sie bildet die Brücke zwischen der Produktvision und den operativen Aufgaben im Backlog. Damit wird sie zur Operationalisierung der Produktstrategie und hilft dabei, Entscheidungen fundierter zu treffen. Gerade in Gesprächen mit Stakeholdern bietet sie eine klare Orientierung, welche Outcomes und Ziele im Fokus stehen. Anstatt über einzelne Features zu diskutieren, lenkt die Roadmap die Aufmerksamkeit auf die übergeordneten Ziele und erlaubt es, neue Anforderungen kritisch zu hinterfragen. Im Scrum-Kontext erweist sich die Product Roadmap als besonders nützlich. Ob im Sprint Planning, bei der Formulierung eines Sprintziels oder im Sprint Review – die Roadmap sorgt für eine klare Verbindung zwischen Vision, Strategie und operativer Umsetzung. Sie zeigt auf, wie das aktuelle Sprintziel auf die langfristigen Produktziele einzahlt. Darüber hinaus unterstützt sie Product Owner, den Fokus zu behalten, etwa in Diskussionen über Prioritäten oder neue Feature-Wünsche. Auch im Kontext von Product Discovery bietet die Roadmap Orientierung. Unsicherheiten, die bei der Entwicklung auftreten, können systematisch angegangen werden. Sie ermöglicht es, Hypothesen oder Annahmen gezielt zu priorisieren und ihre Relevanz für das Gesamtbild zu bewerten. Dabei wird der iterative Charakter der Roadmap deutlich: Neue Erkenntnisse führen zu Anpassungen, um sicherzustellen, dass das Produkt den Anforderungen des Marktes gerecht wird. Product Roadmaps in der täglichen Arbeit einzusetzen erfordert Engagement und Disziplin. Sie ist mehr als nur ein Dokument – sie ist ein zentraler Bestandteil der Produktarbeit und unterstützt dabei, langfristige Ziele mit den täglichen Aufgaben zu verbinden. Indem sie regelmäßig reflektiert und angepasst wird, trägt sie dazu bei, die Produktentwicklung effektiv und zielgerichtet zu gestalten.

In der dieser Folge der Produktwerker spricht Tim mit Götz Müller, einem erfahrenen Experten für Lean Management in der Produktentwicklung und Gastgeber des langjährigen Podcasts „Kaizen 2 go“. Gemeinsam beleuchten sie die Verbindung zwischen Lean Thinking und moderner agiler Produktentwicklung. Dabei steht eine zentrale Frage im Fokus: Was können Product Owner und Produktmanager von den Prinzipien des Lean Product Development lernen? Götz Müller bringt eine beeindruckende Expertise mit. Seit den 1990er Jahren beschäftigt er sich intensiv mit Lean Thinking, das ursprünglich im Kontext von Toyota und der Automobilindustrie entstand. Der Grundgedanke dabei ist ebenso einfach wie kraftvoll: Verschwendung vermeiden und den Wertstrom optimieren – vom ersten Kundenwunsch bis hin zur tatsächlichen Lieferung des Produkts. Lean Thinking ist auch in der digitalen Produktentwicklung relevant. Obwohl Lean oft mit der Massenproduktion assoziiert wird, lassen sich viele Prinzipien übertragen. Lean Management fordert beispielsweise, den Entwicklungsprozess kontinuierlich zu verbessern und stets die Perspektive des Kunden einzunehmen – sei es ein externer Kunde oder ein interner Abnehmer, wie etwa die Produktion in der Hardwareentwicklung. Ein spannender Aspekt ist die Rolle des sogenannten Chief Engineers im Lean-Kontext. Dieser definiert das Produkt in seiner Gesamtheit und trägt die Verantwortung dafür, dass alle Beteiligten auf ein gemeinsames Ziel hinarbeiten. Diese Rolle zeigt Parallelen zur Product-Owner-Rolle in Scrum, geht jedoch weit darüber hinaus, indem sie strategische, technische und menschliche Dimensionen miteinander verbindet. Die Diskussion dreht sich zudem um die Herausforderungen, die entstehen, wenn Hardware- und Softwareentwicklung eng verzahnt sind. Hier betont Götz, dass unterschiedliche Entwicklungszyklen und „Sprachen“ der beiden Bereiche oft zu Missverständnissen führen können. Ein tiefes Verständnis der jeweiligen Bedürfnisse und klare Kommunikation sind essenziell, um diese Hürden zu überwinden. Ein zentrales Learning aus Lean Thinking für Product Owner ist die Bedeutung von kontinuierlicher Verbesserung. In kleinen, iterativen Schritten sollte nicht nur das Produkt, sondern auch der gesamte Entwicklungsprozess optimiert werden. Dabei geht es nicht nur darum, effizient zu arbeiten, sondern vor allem effektiv – mit einem klaren Fokus auf den tatsächlichen Mehrwert für den Kunden. Das Gespräch zeigt eindrucksvoll, wie wichtig die Haltung der kontinuierlichen Verbesserung, auch bekannt als Kaizen, für erfolgreiches Produktmanagement ist. Lean Management in der Produktentwicklung bietet eine wertvolle Perspektive, um in einem unsicheren und komplexen Umfeld bessere Entscheidungen zu treffen. Die Verbindung von Lean und agilem Denken ermöglicht es, nicht nur schneller zu liefern, sondern auch langfristig nachhaltige Werte zu schaffen. Eine wertvolle ältere Folge unserer Podcasts in diesem Zusammenhang gibt es auch: - Kennt Kanban Product Owner? (mit Michael Mahlberg) Wer tiefer in das Thema einsteigen möchte, findet weitere wertvolle Inhalte im Podcast „Kaizen2go“ von Götz Müller. Viel weiteres Material gibt es auf seiner Webseite https://www.geemco.de/ Für Product Owner und Produktmanager, die ihre Arbeit um Lean-Prinzipien bereichern wollen, ist dies eine hervorragende Quelle der Inspiration. Und wer weitere Fragen an Götz Müller hat oder bzgl. Unterstützungsbedarf mit ihm reden möchte, kommt auch über sein LinkedIn-Profil sehr gut mit ihm in Kontakt. Wir hoffen, dass du einige neue Impulse aus den Erfahrungen von Götz gewinnen konntest. Hast du selber schon explizite Erfahrungen mit Lean Management gemacht und magst darüber berichten? Wir Produktwerker freuen uns, wenn du mit uns deine Tipps zu diesem Thema mit anderen Hörerinnen und Hörern teilst. Lass uns gerne einen Kommentar auf unserer Webseite oder auf LinkedIn.

In dieser Folge erzählt Dominique, warum er in diesem Jahr auf Themen statt klassischer Ziele setzt. Üblicherweise nimmt er sich jedes Jahr konkrete Ziele vor, doch oft bleibt das Gefühl, nicht wirklich zufriedenstellend voranzukommen. Daher hat er für 2025 einen neuen Ansatz gewählt: Ein Meta-Thema, das als Leitfaden für das gesamte Jahr dient. Nach einer ausführlichen Abwägung entschied er sich für das Thema Gesundheit. Um es greifbarer zu machen, unterteilte er es in drei Dimensionen: - Körperliche Gesundheit: Bewegung, Schlaf und Vorsorge. - Mentale Gesundheit: Stressreduktion, Achtsamkeit und kreative Hobbys. - Soziale Gesundheit: Beziehungen pflegen, neue Kontakte knüpfen. Für jede Dimension sammelte er 50 Ideen, um aktiv daran zu arbeiten – von Spaziergängen bis hin zu Freiwilligenarbeit. Diese Listen bieten Inspiration und Flexibilität, um je nach Bedarf neue Wege auszuprobieren. Wöchentlich überprüft Dominique mithilfe von Selbstauskunft, Tracking-Tools und Reflexion, wie es ihm in den drei Bereichen geht. So kann er seinen Fokus flexibel anpassen und gezielt dort ansetzen, wo er sich verbessern möchte. Sein Ansatz: Flexibilität statt Frust, Ganzheitlichkeit und Motivation durch Vielfalt. Ob das ganze funktioniert? Das kann Dominique jetzt noch nicht sagen, aber einen Versuch ist es wert.

Die Aussage "Agile is dead" macht aktuell die Runde und sorgt für lebhafte Diskussionen auch in der Product-Owner-Community. Ist das Ende agiler Methoden wirklich erreicht, oder handelt es sich um eine missverstandene These? In dieser Folge der Produktwerker spricht Kai Simons mit Oliver über diese Frage und mögliche Auswirkungen auf Product Owner. Kai Simons, Gründer von Agile Growth und Certified Scrum-Trainer der Scrum Alliance, beleuchtet, warum der Ruf nach dem "Tod von Agilität" in der Luft liegt. Dabei sieht er die Wurzeln dieser Aussage weniger in einem Versagen der agilen Prinzipien, sondern vielmehr in der Art und Weise, wie diese umgesetzt wurden. "Agile Methoden sind leicht zu verstehen, aber schwer zu meistern", betont Kai. Viele Organisationen scheitern nicht an den Ideen, sondern an der konsequenten Transformation und den Rahmenbedingungen, die dafür notwendig sind. Für Product Owner bringt diese Diskussion einige Herausforderungen und Chancen mit sich. Die Rolle erfordert nicht nur fachliche Expertise, sondern auch Leadership-Qualitäten und die Fähigkeit, eine klare Produktvision zu entwickeln und zu kommunizieren. Kai teilt aus seiner Erfahrung, wie oft die falschen Personen diese Verantwortlichkeiten übernehmen, ohne den nötigen Mut, Entscheidungen zu treffen oder die strategische Weitsicht mitzubringen. Dieses Missverständnis trägt zu dem Frust bei, der Agilität als gescheitert erscheinen lässt. Ein zentraler Punkt der Diskussion ist das Vertrauen – sowohl in die eigenen Fähigkeiten als Product Owner als auch in das Team und die Organisation. Nur wenn Product Owner und Teams das Vertrauen aufbauen und halten können, lassen sich agile Prinzipien effektiv umsetzen. Die Verbindung zwischen den agilen Werten und der Realität im Unternehmen ist entscheidend. In vielen Fällen fehlen jedoch die Unterstützung durch Scrum Master oder ein Verständnis dafür, wie die Zusammenarbeit mit Entwicklern gestaltet werden muss, um langfristig erfolgreich zu sein. "Agile is dead" muss nicht das Ende agiler Methoden bedeuten. Vielmehr ist es eine Chance, den ursprünglichen Kern agiler Ansätze wiederzuentdecken und neu zu beleben. Es geht um kontinuierliches Lernen, ehrliches Feedback und die Bereitschaft, an sich selbst und den eigenen Prozessen zu arbeiten. Für Product Owner heißt das konkret: Die Bereitschaft, Führungsqualitäten zu entwickeln, sich mit den Bedürfnissen des Teams auseinanderzusetzen und die agile Transformation aktiv mitzugestalten. Wer also glaubt, Agilität sei tot, sollte genau hinhören: Agilität lebt dort weiter, wo Menschen mutig Verantwortung übernehmen, wo Teams und Organisationen bereit sind, Veränderungen zu wagen, und wo die Prinzipien nicht als Checkliste, sondern als Leitlinien für echte Zusammenarbeit verstanden werden.

iesmal geht's um die Jobsuche als Product Owner oder Produktmanager in den aktuellen schwierigen wirtschaftlichen Zeiten. Tim und Dominique beleuchten die momentanen Herausforderungen und geben wertvolle Tipps, wie sich Produktmenschen besser positionieren können, um eine neue Stelle zu finden. Ein Hauptgrund für die schwierige Situation vieler Product Owner ist der wirtschaftliche Druck, dem Unternehmen aktuell ausgesetzt sind. Stellenabbau in agilen Teams und das Zurückfahren von externen Beratungs- und Freelance-Verträgen gehören zu den häufigsten Szenarien. Vor allem Branchen wie die Automobilindustrie oder energieintensive Industrien wie Stahl sind stark betroffen. In vielen Unternehmen wird zusätzlich wieder verstärkt der Fokus auf die Arbeit vor Ort - anstelle von vorrangiger Remote-Tätigkeit - gelegt. Dies schränkt die Flexibilität der Jobsuche wieder oft eher auf einen lokalen Radius ein. Doch auch abseits solcher äußeren Faktoren stehen viele Product Owner vor einer Herausforderung: die eigene Rolle und ihren Wertbeitrag klar zu kommunizieren. Product Owner werden oft lediglich als "Backlog-Schubser" wahrgenommen, wenn es ihnen nicht gelingt, ihre tatsächliche Verantwortung für das Produkt und damit ihren Einfluss auf das Geschäftsergebnis sichtbar zu machen. Es erscheint derzeit besonders wichtig, den eigenen Beitrag zur Vermeidung von Fehlinvestitionen oder zur Steigerung der Produktqualität konkret darzustellen – etwa durch Kennzahlen oder Erfolgsgeschichten. Darüber hinaus raten Tim und Dominique, die eigene Positionierung zu schärfen. Es geht darum, eine klare Expertise zu vertreten - sei es in der Product Discovery, der Delivery oder anderen Schlüsselthemen der Produktentwicklung. Der Aufbau eines gepflegten LinkedIn-Profils ist dafür übrigens unerlässlich; genauso wie die Vernetzung innerhalb der Community. Events wie das Product Lean Coffee oder andere Austauschformate bieten Gelegenheiten, sich zu zeigen, von anderen zu lernen und potenzielle Jobmöglichkeiten zu entdecken. Ein weiterer Tipp: wagt den Blick über den Tellerrand! Die Unterschiede zwischen den Rollen eines Product Owners und eines Produktmanagers sind in vielen Unternehmen fließend. Aber auch Job Beschreibungen links und rechts davon sollten derzeit in Betracht gezogen werden. Wer seine Suche erweitert, hat meist bessere Chancen, eine passende Position zu finden. Zuletzt appellieren Tim und Dominique an die Community und ihr Netzwerk, eine aktive Unterstützung anzubieten – sei es durch das Teilen von Stellenangeboten oder durch die direkte Vermittlung. Gerade in schwierigen Zeiten können solche Verbindungen den entscheidenden Unterschied machen. Abschließend ermutigen sie, trotz aller Herausforderungen optimistisch zu bleiben und auch kleinere Rückschritte in Kauf zu nehmen, um durch diese wirtschaftliche Durststrecke zu navigieren. Denn eines ist klar: Die aktuelle Lage wird nicht von Dauer sein, und eine gute Vorbereitung ist der Schlüssel für zukünftige Chancen bei der Jobsuche als Product Owner und Produktmanager. Hier die Links zu erwähnten Empfehlungen: - Link zur Community Reihe "Product Lean Coffee", bei dem Tim und Dominique ehrenamtlich im Orgateam sind: https://www.linkedin.com/groups/12524562/ - Buch von April Dunford: Obviously Awesome: How to Nail Product Positioning so Customers Get It, Buy It, Love It Und auch noch die Links zu alten erwähnten Folgen: - Jobsituation für Product Owner & digitale Produktmanager - Sei dein eigenes Produkt! – Weiterentwicklung für Product Owner

Produktstrategie ist ein herausforderndes Thema – unterschiedlichste Strategieansätze, sperrige Begriffe, hohe Erwartungen und der Druck, „richtig“ zu entscheiden, machen es vielen schwer, sich darauf einzulassen. Doch genau hier setzt diese Folge der Produktwerker an. Zusammen mit dem Strategiexperten Markus Andrezak beleuchtet Oliver, wie Product Owner:innen sich effektiv mit Strategieansätzen auseinandersetzen können, ohne in lähmenden Perfektionismus zu verfallen. Was euch immer klar sein sollte: Strategie ist kein abgeschottetes Konzept für eine exklusive Gruppe in einem Unternehmen. Es geht vielmehr darum, klare, bewusste Entscheidungen zu treffen, die Orientierung geben und sich kontinuierlich anpassen lassen. Ansätze wie das Playing-to-Win-Framework von Roger Martin machen dies greifbar. Anstatt einen starren Plan zu schaffen, bietet das Framework die Möglichkeit, flexibel und iterativ zu arbeiten. Ein weiterer wichtiger Punkt ist die regelmäßige Beschäftigung mit Strategie. Markus betont, dass Strategie nicht in einmaligen Offsites entsteht, sondern in kleinen, stetigen Schritten, die Teil des Arbeitsalltags werden. Regelmäßige Reflexionen – zum Beispiel in Meetings oder Sprint Reviews – helfen, Klarheit zu schaffen und die Strategie an den aktuellen Kontext anzupassen. Diese Routine trainiert nicht nur die Fähigkeit, über Strategie zu sprechen, sondern verbessert auch die Kommunikation innerhalb des Teams. Doch es gibt nicht das eine richtige Framework. Vielmehr geht es darum, aus den vielen Strategieansätzen einen Ansatz zu wählen, der zu den eigenen Bedürfnissen und dem Team passt. Ein zentraler Tipp für Product Owner:innen ist, klein anzufangen und iterativ vorzugehen. Das Ziel ist, Strategieansätze so in den Arbeitsalltag zu integrieren, dass sie praktikabel bleiben und echten Mehrwert schaffen. Wer das schafft, wird feststellen, wie sehr eine klare Strategie die tägliche Arbeit erleichtert – sei es bei der Priorisierung des Backlogs oder der Zieldefinition für das Team. Diese früheren Folgen werden in dieser Episode referenziert: - Produktstrategie in die Praxis bringen - mit Markus Andrezak - The Product Field - Framework - The Decision Stack Und diese anderen älteren Folgen können wir in diesem Kontext empfehlen: - Eine Produktstrategie entwickeln - Von der Produktstrategie zum Product Backlog (mit Roman Pichler) - Eine Produktstrategie ohne Canvas erarbeiten (mit Tim Herbig) Frühere Folgen mit Markus Andrezak: - Warum scheint die Product Owner Rolle so schwer zu sein? (Folge 3 und immer noch eine der meistgehörten Folgen!) - Business- oder Nutzersicht: Welchen Blickwinkel sollte ein PO einnehmen? (neben Markus auch mit Sohrab Salimi - und durch die zwei Experten ausnahmsweise etwas länger als sonst) Wer weitere Fragen an Markus Andrezak hat oder mit ihm in Kontakt treten möchte, erreicht ihn am besten über sein LinkedIn-Profil oder über seine Webseite (ueberproduct.de). Weitere Infos zum Lernen in der "Strategy Collective Cohorte" gibt es bei der überproduct Academy.

In dieser Folge dreht sich alles um ein Thema, das viele Product Owner in der Praxis betrifft: Mehrere Backlogs. Obwohl die Regel im agilen Kontext „Ein Produkt, ein Product Backlog“ lautet, zeigt die Realität oft andere Szenarien. Dominique und Tim erklären wie man als Product Owner damit umgehen kann, wenn man gezwungen ist, mehr als ein Backlog zu verwalten. Bei mehreren Backlogs gibt es einige Herausforderungen. Oft entstehen sie, wenn ein Team an mehreren Produkten oder Services arbeitet, was die Organisation von Prioritäten erschwert. Ein weiteres häufiges Szenario ist die Aufteilung von Aufgaben nach Prozessschritten, etwa ein separates UX-Backlog oder ein Bug-Backlog. Diese unterschiedlichen Quellen und Aufteilungen führen leicht zu einem Verlust der Übersicht. Was ist wirklich wichtig, und welches Backlog hat Vorrang? Product Owner stehen dann oft vor der Frage, wie sie die Transparenz wahren und gleichzeitig strategisch arbeiten können, ohne sich in operativen Details zu verlieren. Die Lösung liegt häufig in einer besseren Organisation und klaren Strukturen. Statt mehrere Backlogs isoliert zu pflegen, empfiehlt es sich, alle Aufgaben in einem System wie Jira zu bündeln und mit Labels oder Filtern zu arbeiten. Dies erleichtert die Priorisierung und schafft eine „Single Source of Truth“ für alle Beteiligten. Zudem kann es sinnvoll sein, Ideen oder potenzielle Features zunächst außerhalb des eigentlichen Product Backlogs zu sammeln. Diese sollten jedoch nicht als zusätzliche Backlogs betrachtet werden, sondern als unterstützende Tools im Discovery-Prozess. Sobald eine Idee reif genug ist, gehört sie ins Product Backlog, um die Arbeit des Teams zu strukturieren und zu priorisieren. Ein weiterer Ansatz ist die Visualisierung der Arbeitsprozesse. Indem die Reise von Ideen und Anforderungen durch den Produktentwicklungsprozess sichtbar gemacht wird, können Teams und Stakeholder besser verstehen, wo welche Prioritäten liegen und welche Schritte nötig sind, um Ziele zu erreichen. Gleichzeitig gilt: Mut zur Einfachheit. Nicht jede Idee oder jedes Feedback muss umgesetzt werden. Wer mutig genug ist, Überflüssiges zu eliminieren, schafft Raum für das Wesentliche. Am Ende gilt vor allem: Für Product Owner, die mit mehreren Produkten und Backlogs arbeiten, ist eine klare Priorisierung entscheidend. Wenn spontane Aufgaben auftreten, hilft eine vorab festgelegte Rangordnung, Konflikte zu vermeiden und die Effizienz zu steigern. Weitere Tipps bekommt ihr in Folgen zu ähnlichen Themen: - Product Backlog organisieren (https://produktwerker.de/product-backlog-organisieren/) - Features wegwerfen - was braucht es dafür außer Mut? (https://produktwerker.de/features-wegwerfen/) - Das Product Goal und seine Bedeutung für Product Owner (https://produktwerker.de/das-product-goal-und-seine-bedeutung-fuer-product-owner/) - LeSS aus Product Owner Sicht und aktuelle Skalierungstrends (https://produktwerker.de/less-als-po/) - Product Principles (https://produktwerker.de/product-principles/)

Diesmal dreht sich alles um das spannende Thema AI Tools für Produktmanagement. Tim Klein spricht mit Alexej Antropov, dem Entwickler des sogenannten KI-Radars. Dieses Radar bietet eine strukturierte Übersicht über die Vielzahl von KI-Tools im Produktmanagement und gibt damit eine gute Orientierung. Alexej erklärt, wie er aus seiner Erfahrung und intensiven Recherche diesen Überblick geschaffen hat, der Product Ownern und Produktmanagern einen tollen Marktüberblick der wichtigsten AI Tools in der schnelllebigen Welt der KI-Technologien gibt. Das KI-Radar ist so konzipiert, dass es nach Rollen und Anwendungsfällen in der Produktentwicklung strukturiert ist. Egal, ob man als Designer, Product Owner, Engineer oder im Team tätig ist – das Radar hilft, relevante Tools zu entdecken und deren Reifegrad einzuschätzen. Das Radar umfasst dabei nicht nur etablierte Anwendungen wie Microsoft Copilot, sondern auch experimentelle und vielversprechende Tools. Seine Motivation ist es, die Innovationskraft von Teams zu steigern und das Thema KI pragmatisch und praxisnah in den Arbeitsalltag zu integrieren. Im Gespräch hebt Alexej Antropov hervor, dass die Nutzung von KI-Tools seines Erachtens nicht nur die Effizienz erhöhen kann, sondern auch völlig neue Möglichkeiten eröffnet; etwa beim schnellen Erstellen von Prototypen oder der Analyse von Nutzerinterviews. Ein besonderer Fokus liegt dabei auf der Frage, wie Unternehmen das Potenzial von KI erschließen können, ohne sich in der Komplexität des Themas zu verlieren. Alexej empfiehlt eine iterative Herangehensweise: klein anfangen, experimentieren und lernen. Das Radar selbst ist ein dynamisches Projekt, das sich durch kontinuierliches Feedback (auch von euch!) und neu entdeckte Tools weiterentwickelt. Alexej sieht es als Community-Tool, das also auch durch Beiträge anderer Produktmenschen lebt. Datenschutz und die europäische Gesetzgebung sind für ihn wichtige Kriterien bei der Auswahl der Tools, was das Radar besonders für Unternehmen in der EU attraktiv machen dürfte. Wer sich als Produktmensch mit KI auseinandersetzt, hat die Chance, nicht nur effizienter im Produktmanagement zu arbeiten, sondern auch frühzeitig neue Kompetenzen zu entwickeln. Doch wie fängt man an mit KI zu nutzen? Alexej rät: Einfach Machen! Denn jeder muss irgendwo anfangen. Sein Tipp lautet daher: Geht das Thema einfach in eurem eigenen Tempo an, Hauptsache ihr beginnt damit. Das KI-Radar bietet hierfür eine wertvolle Orientierungshilfe und guten Startpunkt. Es lädt dazu ein, neugierig zu sein und die Möglichkeiten von KI aktiv zu nutzen. Wertvolle Quellen: - Das KI-Radar für Produktmanagement & Software-Entwicklung findet ihr in der jeweils aktuellen Fassung hier: https://www.beyondbacklog.de/p/das-ki-radar-fur-produktmanagement-und-software-entwicklung - Alexej hat sein KI Radar auch schon mal in einem sehr guten Talk (auf Englisch) vorgestellt. Zu diesem Talk findet ihr hier eine sehr gute und detaillierte Darstellung: https://www.beyondbacklog.de/p/product-tank-munich-orga-fitness-in-the-age-of-ai-tool-radar-web-product-development-dovetail-miro-juttu-claude-uizard - Miro im AI Einsatz (inkl. Link zum Prototyping) und den Post von Alexej dazu gibt es hier: https://www.beyondbacklog.de/p/auswerten-von-kunden-interviews-mit-miro-ai-guide-template Folgende ältere Podcast-Episoden werden von Tim im Gespräch genannt, die super zu dieser Folge passen: - AI als Wingman für Product Owner - Produktentwicklung von AI Produkten - Wie No-Code Tools Produktteams helfen können - Guerilla Discovery - wenn der Kontext Product Discovery nicht aktiv unterstützt Wer weitere Fragen an Alexej hat oder ihm selber gute AI Tools für Produktmanagement empfehlen kann, die er noch nicht auf seinem Radar hat, erreicht ihn am besten über sein LinkedIn Profil (linkedin.com/in/alexejantropov/) oder per Mail: alexej@valuerebels.com. Seine Website und vor allem seinen Newsletter findet ihr unter beyondbacklog.de

Das Abbrechen eines Sprints ist ein seltenes, aber einschneidendes Ereignis im agilen Arbeiten. Aber wann ist es sinnvoll, einen Sprint abzubrechen, und was passiert danach? Obwohl Sprints selten abgebrochen werden, kann dies unter bestimmten Umständen hilfreich und richtig sein, um Zeit und Ressourcen zu sparen. Ein zentraler Aspekt rund um die Idee einen Sprint abzubrechen ist die Rolle des Sprintziels. Wenn ein Sprintziel während des Sprints obsolet wird, sei es durch neue Erkenntnisse, technologische Hürden oder strategische Entscheidungen, ist dies ein klarer Grund für einen Sprintabbruch. Zum Beispiel kann eine Änderung auf Kundenseite dazu führen, dass eine zuvor geforderte Funktionalität gar nicht mehr benötigt wird. Oder es stellt sich während der Arbeit heraus, dass eine geplante technische Lösung so nicht umsetzbar ist. In solchen Situationen stehen Product Owner:innen in der Verantwortung, die richtige Entscheidung zu treffen. Schließlich hat nur er oder sie die Befugnis, einen Sprint abzubrechen. Ein Sprintabbruch erfordert jedoch neben Mut auch eine durchdachte Kommunikation. Das Team und andere Stakeholder:innen müssen einbezogen werden, um die Situation zu bewerten und eine fundierte Entscheidung zu treffen. Dabei wird oft deutlich, dass Transparenz und Zusammenarbeit wichtig sind, um den nächsten Schritt zu planen. Nach dem Abbruch des Sprints gilt es dann gemeinsam zu analysieren, welche Arbeitsergebnisse weiterhin verwertbar sind und welche nicht. Eine Retrospektive hilft, die Arbeitsweise zu reflektieren und mögliche Verbesserungen zu identifizieren. Ein Sprintabbruch kann daher auch eine wertvolle Gelegenheit sein, innezuhalten und sich neu auszurichten. Eine klare Orientierung hilft, den nächsten Sprint effektiv zu planen und das Team auf die neuen Ziele einzustimmen. Dominique und Oliver fragen sich in der Folge auch ob Sprints nicht oft genug abgebrochen werden. Oft fehlt es an klar definierten Sprintzielen oder der Fähigkeit, den Fortschritt während des Sprints zu messen. Diese Faktoren können dazu führen, dass Teams zu lange an Aufgaben festhalten, die nicht den richtigen Mehrwert für Nutzer:innen bieten. Am Ende bleibt, dass es für Product Owner:innen essenziell ist, die Auswirkungen eines Sprintabbruchs zu berücksichtigen und die verbleibende Zeit sinnvoll zu nutzen. Der Abbruch eines Sprints ist kein Zeichen von Scheitern, sondern ein Schritt, der dabei hilft, den Fokus auf das Wesentliche zu richten. ----------------- Ein Sprintabbruch ist selten. Daher interessiert es uns sehr, wie eure Erfahrungen dabei sind. Habt ihr bereits einen Sprint abgebrochen und was habt ihr dabei gelernt? Was könnt ihr anderen mit auf den Weg geben? Schreibt es gerne in den Kommentaren des zur Folge gehörenden Blogbeitrags (https://produktwerker.de/wann-breche-ich-einen-sprint-ab-und-was-mache-ich-danach/) oder auf LinkedIn (https://www.linkedin.com/company/produktwerker/).

In dieser Folge geht's darum Konflikte mit Stakeholdern zu meistern. Konflikte sind im Produktmanagement fast unvermeidlich, da unterschiedliche Interessengruppen oft widersprüchliche Ziele verfolgen. Bernd Joussen, ein erfahrener Coach für Teamentwicklung und Konfliktmanagement (und zugleich auch Konflikt-Mediator), teilt im Gespräch mit Tim seine Einsichten darüber, wie Product Owner solche Spannungen und konfliktbeladenen Situationen erfolgreich handhaben können. Ein Konflikt, so erklärt Bernd, entsteht, wenn zwei oder mehr Parteien unterschiedliche Interessen verfolgen und mit ihren Ansprüchen bzw. Erwartungshaltungen aufeinandertreffen. Er betont die Bedeutung einer bewussten Abgrenzung zwischen strukturellen und zwischenmenschlichen Konflikten. Während die einen oft aus widersprüchlichen Unternehmenszielen resultieren, etwa durch fehlende strategische Orientierung oder technische Limitierungen, betreffen die anderen eher persönliche oder teaminterne Spannungen. In Organisationen gibt es typische Konfliktfelder, wie das Ringen um begrenzte Ressourcen oder unterschiedliche Prioritäten, etwa zwischen Marketing und Produktentwicklung. Solche Spannungen verschärfen sich oft, wenn Stakeholder ihre Interessen stark durchsetzen wollen. Hier können Product Owner ansetzen, indem sie eine Kultur der Empathie und des gegenseitigen Verständnisses fördern. Bernd empfiehlt das Johari-Fenster hierfür als hilfreiches Tool, das den Teammitgliedern dabei hilft, blinde Flecken aufzudecken und durch bewusstes Teilen eigener Bedürfnisse Vertrauen zu stärken. Ein weiterer wertvoller Tipp von Bernd ist die sogenannte Konflikt-Map, ein visuelles Werkzeug, das die Beziehungen und Spannungen zwischen verschiedenen Akteuren anschaulich darstellt. Mit Blitzen und Pfeilen lassen sich so problematische Verbindungen oder Kommunikationslücken verdeutlichen. Diese Methode schafft Klarheit und hilft dem gesamten Team, Konfliktmuster zu erkennen und gezielt anzugehen. Für Bernd ist es wichtig eine gesunde Streitkultur zu pflegen. Konflikte können das Team stärken, wenn sie konstruktiv geführt werden, denn sie bieten Raum für Innovation und Weiterentwicklung. Product Owner können diese Dynamik unterstützen, indem sie regelmäßig Feedback einholen und lernen, souverän mit Kritik umzugehen. Hierfür ist das Buch "Radical Candor" von Kim Scott hilfreich, das praxisnahe Ansätze für eine ehrliche und respektvolle Kommunikation vermittelt. Als praxisnahen Tipp für alle, die ihre Zusammenarbeit verbessern wollen stellt Tim das „How-to-work-with-me“-Dokument vor. Hierbei handelt es sich um eine Art "Bedienungsanleitung für mich selbst", die persönliche Präferenzen und Bedürfnisse beschreibt, damit das Team besser auf mich (und meine Eigenarten und Erwartungshaltungen an den Umgang mit mir) eingehen kann. Dies stärkt nicht nur die Kommunikation, sondern kann auch helfen, potenziellen Konflikten präventiv entgegenzuwirken. Diese Folge mit Bernd Joussen verdeutlicht, dass Konflikte mit Stakeholdern zum Alltag eines Product Owners gehören und nicht vermieden, sondern konstruktiv genutzt werden sollten. Ihr als Product Owner solltet euch daher nicht scheuen, externe Unterstützung durch Coaches oder Mediatoren wie Bernd hinzuzuziehen, um die Konfliktlösung zu erleichtern und die Zusammenarbeit im Team zu fördern. Diese früheren Folgen werden in dieser Episode referenziert: - Umgang mit schwierigen Stakeholdern - Herausforderungen zwischen Product Owner und Developer (frühere Folge mit Bernd Joussen) - Stakeholder Community - Konflikte zwischen Scrum Master und Product Owner Bernd empfiehlt im Gespräch folgende Tools und Bücher: - Johari Fenster - Conflict Map - Birgit Schumacher: Psychologische Sicherheit - Manfred Prior: MiniMax-Interventionen - Kim Scott: Radical Candor - Friedrich Glasl: Konfliktmanagement - Market of Skills Tim erwähnt noch das "How To Work With Me"-Manual.

n dieser Podcastfolge widmen sich Oliver & Tim dem Thema Produktrisiken und beleuchten, welche Herausforderungen Product Owner im Hinblick auf die Risikobetrachtung meistern sollten. Jede Produktentwicklung beinhaltet Risiken mit denen man sich auseinandersetzen und bewusst mit ihnen umzugehen muss. Als Product Owner liegt es im Kern ihrer Verantwortung, mögliche Risiken frühzeitig zu erkennen und Strategien zu entwickeln, um diese zu minimieren. Die beiden sprechen über die Einteilung von Produktrisiken in vier Kategorien: Usability-Risiken (Nutzbarkeit für den Kunden), Value-Risiken (Mehrwert für den Kunden), Business Viability-Risiken (wirtschaftliche Tragfähigkeit) und Feasibility-Risiken (Machbarkeit). Es ist entscheidend, als Product Owner ein Bewusstsein für diese unterschiedlichen Risikobereiche zu entwickeln. Das Verständnis der Kundenbedürfnisse und die fortlaufende Evaluation des Marktes helfen, mögliche Value-Risiken zu reduzieren. Denn nur ein Produkt, welches tatsächlich einen Mehrwert bietet, hat langfristig Bestand. Bei den Business Viability-Risiken liegt der Fokus auf der wirtschaftlichen Tragfähigkeit des Produkts. Ein Produkt mag den Nutzern gefallen und technisch machbar sein, dennoch kann es an einem rentablen Geschäftsmodell scheitern. Es ist dabei von entscheidender Bedeutung, die strategische Ausrichtung des Unternehmens zu berücksichtigen und sicherzustellen, dass das Produkt langfristig den wirtschaftlichen Erfolg unterstützt. Ein wichtiger Aspekt, der in dieser Folge angesprochen wird, ist die Notwendigkeit, über rein technische Risiken hinaus auch ethische Aspekte zu berücksichtigen. Hier kommen Tim und Oliver auf das sogenannte ethische Risiko zu sprechen, bei dem es darum geht, ob ein Produkt moralisch vertretbar ist und im Einklang mit den ethischen Grundsätzen der Organisation steht. Kontinuierliche Product Discovery und die enge Zusammenarbeit mit Stakeholdern können dabei helfen, Produktrisiken frühzeitig zu identifizieren und durch gezielte Tests und Experimente zu mindern. Produktideen werden in der Entstehungsphase auf Annahmen geprüft und in Hypothesen überführt, um auf Basis der Ergebnisse Entscheidungen zu treffen, bevor es in die Product Delivery geht. Dabei kann die Zusammenarbeit in einem sogenannten „Product Trio“ aus Product Owner, Designer und Engineers wertvolle Perspektiven für die Risikobetrachtung eröffnen. Diese Folge bietet praxisnahe Einblicke und viele anschauliche Beispiele, wie Product Owner im täglichen Umfeld Produktrisiken bewerten und Strategien entwickeln können, um Unsicherheiten zu managen und die Erfolgsaussichten ihrer Produkte zu steigern.

Wie sieht die Jobsituation für Product Owner und digitale Produktmanager zum Ende des Jahres 2024 aus? Tim spricht in dieser Episode mit Recruiting-Experte Denny Meier über die aktuelle Marktlage und die Trends für Product Owner und digitale Produktmanager. Denny Meier ist tief drin im Markt für Product Owner und Produktmanager, da er sich schon vor Jahren auf die Vermittlung und Suche von Festangestellten mit solchen Expertisen spezialisiert hat. Denny taucht erstmal tief in die Zahlenwelt ein und bespricht mit Tim u.a., wie sich die Jobtitel und die Anforderungen in diesen Rollen verändern. Dabei geht es aber auch um die Entwicklung des Rollenverständnisses: weg von der reinen Verwaltung des Backlogs hin zu einem stärker wertorientierten Ansatz. Ein weiterer Schwerpunkt der Folge liegt auf der Gehaltssituation und auch dem Gender Pay Gap: wie sehen die aktuellen Gehaltszahlen aus, und welche Unterschiede bestehen zwischen den Geschlechtern? Spannend ist dabei auch der Vergleich bzw. Entwicklung zur Gehalts- und Jobsituation für Product Owner im Jahr 2020, als Denny Meier schon mal in unserem Podcast zu Gast war. Für Senior-Positionen zeigt Denny die zunehmende Bedeutung organisatorischer Themen, Führungskompetenzen und die auch Organisationsentwicklung bei der Suche nach Kandidatinnen und Kandidaten auf. Denny teilt auch Einblicke in die verschiedenen Branchen, die besonders stark nach Talenten suchen. Abschließend gehen die beiden darauf ein, welchen Hintergrund die Leute in diesen Rollen häufig mitbringen und geben wertvolle Tipps für alle, die sich auf der Suche nach einer passenden Position im Produktmanagement befinden. Natürlich ist die Jobsituation für Product Owner und digitale Produktmanager derzeit etwas angespannter, aber gute Chancen gibt es für spannende Profile nach wie vor. Gute Leute werden halt irgendwie immer gesucht. Auf diese früheren Folgen wird im Laufe der Episode verwiesen: Sich als Product Owner auf die Bewerbung vorbereiten - Gast: Denny Meier Der Arbeitsmarkt für Product Owner & Product Leader (Juli 2020) - Gast: Denny Meier AI als Wingman für Product Owner Sei dein eigenes Produkt! – Weiterentwicklung für Product Owner Wenn ihr in den direkten Austausch mit Denny kommen wollt oder weitere Fragen habt, erreicht ihr ihn am besten über sein LinkedIn-Profil. Natürlich könnt ihr ihn auch gerne als suchendes Unternehmen oder als suchende Kandidatin bzw. Kandidat direkt via LinkedIn ansprechen.

In dieser Folge des Produktwerker-Podcast dreht sich alles um Continuous Delivery aus der Perspektive eines Product Owners. Dominique und Oliver beleuchten die Unterschiede zwischen Continuous Integration, Continuous Delivery und Continuous Deployment und tauschen sich darüber aus, wie wichtig diese Praktiken auch für Produktmenschen sind, um kontinuierlich Mehrwert zu liefern. Continuous Delivery hingegen ermöglicht im Gegensatz zu früher üblichen umfangreichen Releases, kleinere Änderungen regelmäßig auszuliefern und diese frühzeitig in produktionsnahen Umgebungen zu testen. Einer der wichtigsten Argumente für Continuous Delivery ist die Risikominimierung. Durch kontinuierliches Testen in Staging-Umgebungen lassen sich potenzielle Probleme frühzeitig erkennen und beheben, bevor sie live gehen. Dies erhöht nicht nur die Qualität, sondern schafft auch Sicherheit für den Product Owner und das Team. Dominique und Oliver diskutieren in diesem Kontext den Einsatz von Feature-Toggles, mit denen Funktionen gezielt für bestimmte Nutzergruppen aktiviert werden können, um Feedback zu erhalten und die Einführung neuer Features zu kontrollieren. Durch Continuous Delivery wird der Übergang von der Entwicklung zur Auslieferung fließender und transparenter, was wiederum die Zusammenarbeit und Abstimmung mit Stakeholdern erleichtert. Continuous Delivery bekomme ich als Product Owner nicht geschenkt, es erfordert eine Investition in technische Infrastrukturm welche letztendlich die Produktqualität und die Liefergeschwindigkeit verbessert. Dabei sollte das Team regelmäßig reflektieren, wie viel Aufwand bei der Integration und Auslieferung erforderlich ist, um den Nutzen einschätzen zu können. Continuous Delivery hilft somit, kontinuierlich wertvolle und getestete Produktinkremente bereitzustellen und ermöglicht es Product Ownern, flexibler auf Veränderungen zu reagieren und schneller auf die Bedürfnisse der Nutzer einzugehen.

In dieser Folge geht es um die Herausforderungen und Chancen des Produktmanagements in regulierten Branchen. Tim spricht heute mit Deniz Dogan, Product Management Consultant bei den Product People, über die spezifischen Anforderungen, die auf Product Owner in regulierten Umfeldern zukommen. Regulierung stellt natürlich häufig eine Hürde dar, weil sie viele Freiheiten während der Produktentwicklung einschränkt. Doch dies sollte nicht nur als Beschränkung gesehen werden. Vielmehr bietet die Gesetzeslage oft auch Spielraum, wie Regelungen umgesetzt werden, was Raum für kreative Lösungen schafft. Ein Beispiel in dieser Folge ist der Digital Services Act (DSA), bei dem zwar Vorgaben zu Transparenz und Meldemöglichkeiten erfüllt werden müssen, aber nicht festgelegt ist, wie dies genau zu geschehen hat. Hier zum Beispiel hat Deniz Dogan durch sorgfältige Analyse der Vorgaben und enge Zusammenarbeit mit dem Compliance-Team innovative Ansätze gefunden, um Anforderungen effizient zu erfüllen, ohne unnötigen Aufwand zu erzeugen. Die enge Zusammenarbeit mit Compliance-Teams ist besonders wichtig, um das Produktmanagement in regulierten Branchen zu erleichtern. Deniz betont in dieser Folge, wie wichtig es ist, frühzeitig und proaktiv den Dialog mit diesen Abteilungen zu suchen. Oft wird aus Unsicherheit lieber ein konservativer Ansatz gewählt, der jedoch nicht immer nötig ist. Indem Product Owner die gesetzlichen Rahmenbedingungen genau verstehen und kritisch hinterfragen, können sie unnötige Aufwände vermeiden und gleichzeitig rechtskonform bleiben. So wird aus einem vermeintlichen Hindernis eine Gelegenheit für Produktverbesserungen und damit eine echte Chance. Besonders in regulierten Branchen zeigt sich zudem, dass Vorschriften oft nicht eindeutig sind, was Raum für Interpretation lässt. Dies führt zu Ambiguität, die zwar zusätzliche Komplexität schafft, aber auch Gestaltungsspielräume eröffnet. Dies bietet eine Chance, Wettbewerbsvorteile zu erzielen, indem Unternehmen die Anforderungen nicht nur erfüllen, sondern die Art wie sie die Erfüllung dieser Regulation meistern zu einem Selling Point machen. Ein Beispiel hierfür ist die Barrierefreiheit, bei der sich Unternehmen durch besonders proaktive Maßnahmen im Markt differenzieren können. Letztlich kommt es darauf an, als Product Owner nicht nur die Vorschriften zu erfüllen, sondern den Mehrwert darin zu erkennen, wie ein Produkt dadurch besser und sicherer gestaltet werden kann. Wer bereit ist, die Regeln genauer unter die Lupe zu nehmen und in den Dialog mit den richtigen Stakeholdern zu gehen, kann auch in streng regulierten Märkten innovativ agieren und sich einen Vorsprung verschaffen. Im Produktmanagement in regulierten Branchen geht es also nicht nur darum, sich an Gesetze zu halten, sondern diese auch als Chance zu nutzen, Produkte nachhaltig besser zu machen. Diese früheren Folgen werden in dieser Episode referenziert: - Guerilla Discovery - wenn der Kontext Product Discovery nicht aktiv unterstützt - Barrierefreiheit von digitalen Produkten - Umgang mit schwierigen Stakeholdern Wer weitere Fragen an Deniz hat oder mit ihm in Kontakt treten möchte, erreicht ihn am Besten über sein LinkedIn-Profil oder über die Product People (getproductpeople.com). Von Deniz Dogan gibt es zudem auch ein englisches Webinar der Product People auf YouTube zum Thema ”Product Management in regulated industries: Navigating the Digital Service Act”. Wir hoffen, dass du einige neue Impulse zum Thema reguliertes Umfeld aus den Erfahrungen von Deniz Dogan ableiten konntest. Bist du selber vielleicht auch im Produktmanagement und von Regulation betroffen? Wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite.

In dieser Folge dreht sich alles um das Arbeiten als Product Owner im Home Office. Seit der Corona-Pandemie ist Home Office für viele POs zur Normalität geworden, was sowohl Chancen als auch Herausforderungen mit sich bringt. Oliver und Dominique diskutieren, wie sich die Verantwortung eines Product Owners durch die veränderten Arbeitsbedingungen verschoben hat und welche Auswirkungen dies auf die tägliche Arbeit hat. Eine der größten Veränderungen betrifft die Kommunikation besonders mit dem eigenen Team. Obwohl die virtuelle Kommunikation via Slack oder Videokonferenzen viele spannende Möglichkeiten bietet, gibt es Aspekte, die im Home Office schwerer umsetzbar sind. Spontane Gespräche oder das schnelle „Zurufen“ einer Frage im Teamraum vor Ort fehlen, was den Austausch im Team verlangsamen kann. Product Owner müssen darüber hinaus darauf achten, dass trotz Remote-Arbeit keine wichtigen Informationen verloren gehen. Andererseits bietet das Home Office aber auch einige Vorteile: Die Flexibilität ermöglicht es, sich besser auf bestimmte Aufgaben zu fokussieren und tiefere, ungestörte Arbeit zu leisten. Eine weitere kommunikative Herausforderung ist es, die Beziehung zu den Stakeholdern zu pflegen. Im Büro gibt es diverse Möglichkeit sich informell auszutauschen – etwa an der Kaffeemaschine – während im Home Office solche Gelegenheiten fehlen. Hier sind kreative Ansätze gefragt, um den Kontakt nicht nur formell, sondern auch auf einer persönlichen Ebene aufrechtzuerhalten. Ein „Stakeholder-Daily“ könnte beispielsweise helfen, die Entscheidungsprozesse zu beschleunigen, indem regelmäßige kurze Meetings stattfinden. Doch Arbeiten im Home Office bietet nicht nur Hürden, sondern auch einige neue Chancen. Product Owner können durch die zunehmende Flexibilität Jobmöglichkeiten im gesamten deutschsprachigen Raum, oder sogar darüber hinaus, wahrnehmen. Zudem verbessern digitale Tools wie Miro oder Confluence die Zusammenarbeit und die Dokumentation. Das Arbeiten im virtuellen Raum ermöglicht es, transparenter zu agieren und Prozesse effizienter zu gestalten. Ein großer Vorteil des Home Offices ist auch die Möglichkeit, den eigenen Arbeitsrhythmus flexibler zu gestalten. Product Owner können tiefer in Aufgaben eintauchen, ohne von äußeren Faktoren im Büro abgelenkt zu werden. Auf eines sollte man aber achten: Die klare Trennung zwischen Arbeit und Privatleben fällt oft schwer, besonders wenn man nicht in einem separaten Arbeitszimmer, sondern vielleicht am Küchentisch arbeitet. Insgesamt gibt diese Folge praktische Tipps, wie du die Herausforderungen des Home Offices meistern kannst. Als PO solltest du deinen Arbeitsalltag aktiv gestalten und nicht einfach nur den Umständen ausgeliefert sein.

In der aktuellen Folge des Produktwerker-Podcasts dreht sich alles um ein spannendes Thema für Product Owner: die Progress Design Map. Tim hat erneut den Experten Peter Rochel von UXTO zu Gast, der zusammen mit seinem Team eine Weiterentwicklung des klassischen Value Proposition Canvas vorstellt. Mit der Progress Design Map will UXTO den Jobs-to-de-Done Prozess auf ein neues Level heben, indem die Herausforderungen und Grenzen des Value Proposition Canvas im Rahmen des "Wheel of Progress" angegangen werden. Peter gibt zunächst eine kurze Einführung in das Jobs-to-be-Done-Konzept, das in der Produktentwicklung dafür sorgt, die Bedürfnisse und Aufgaben der Kunden besser zu verstehen. Wie Peter erklärt, war das Value Proposition Canvas bislang zwar ein guter Anfangspunkt, aber in der Praxis stößt es oft an seine Grenzen. Besonders bei der Frage, wie ein Produkt über verschiedene Entwicklungsphasen hinweg optimal gestaltet und am Markt positioniert werden kann, hatte der Canvas Schwächen gezeigt. Hier setzt die Progress Design Map an. Sie ist speziell darauf ausgelegt, die Erkenntnisse aus Kundeninterviews und der kontinuierlichen Marktforschung zu strukturieren und direkt in die Produktentwicklung einzubringen. Im Gegensatz zum herkömmlichen Value Proposition Canvas berücksichtigt die neue Methode die fünf unterschiedlichen Phasen, die ein Kunde durchläuft – die Passive Suche, Aktive Suche, Entscheidung, Erste Nutzung und Wiederholte Nutzung. Peter Rochel erklärt, dass es darum geht, gezielt zu entscheiden, welche Features und Funktionen in welchem Entwicklungsstadium des Produkts priorisiert werden. Statt wahllos alles zu entwickeln, liegt der Fokus darauf, die wertvollsten Fortschritte für den Kunden zu erzielen und dabei nicht unnötig Ressourcen zu verschwenden. Gerade in den frühen Phasen, so Peter, sei es wichtig, den Kunden nicht mit zu vielen Details zu überfordern. Erst wenn ein konkreter Bedarf erkennbar ist, wird das Produkt sukzessive weiterentwickelt. Tim und Peter diskutieren auch die Bedeutung von Ereignissen, die das Kundenverhalten beeinflussen. Sie sprechen über die "limitierenden Kontexte", in denen ein Produkt genutzt wird, und wie diese den Entwicklungsprozess beeinflussen sollten. Peters Beispiel hier ist die Nutzung einer App für urbane Mobilität bei schlechtem Netzempfang oder Regen. Hier wird schnell klar, dass es nicht nur um technische Features geht, sondern darum, wie diese in spezifischen Nutzungsszenarien wirklich einen Fortschritt für den Nutzer bringen. Ein gutes Problemverständnis ist entscheidend, um nicht nur Produkte, sondern echte Lösungen zu liefern. Peter plädiert dafür, frühzeitig Feedback von echten Nutzern zu sammeln und dieses gezielt in die Weiterentwicklung einfließen zu lassen. So wird vermieden, dass sich ein Backlog mit irrelevanten Features füllt, die später mühsam wieder aussortiert werden müssen. Für alle, die tiefer in das Thema einsteigen möchten, empfiehlt Peter die Nutzung der Progress Design Map, welche bald unter Creative Commons frei verfügbar ist. Es ist ein starkes Werkzeug, um die komplexen Zusammenhänge im Innovationsprozess besser zu strukturieren und als Team effizienter zu arbeiten. Die Progress Design Map ist ein Schritt in Richtung einer noch nutzerzentrierteren und datengetriebenen Arbeitsweise. Hört rein und erfahrt, wie ihr eure Produktentwicklung optimieren und eure Produkte noch erfolgreicher machen könnt! Die frühere Folge zur "Jobs-to-be-Done" Methode mit Gast Peter Rochel findet ihr hier: - Mit "Jobs to Be Done"-Interviews zum besseren Kundenverständnis Wir hoffen, dass du einige neue Impulse zum Thema Kundenverständnis aus den Erfahrungen von Peter Rochel ableiten konntest. Bist du selber vielleicht auch aktiv in der Nutzung des Value Proposition Canvas? Dann schau dir mal die Progress Design Map als spannende Weiterentwicklung an.

In dieser Folge unseres Podcasts dreht sich alles um die Herausforderungen und Best Practices rund um die Releaseplanung, insbesondere der Planung und Umsetzung großer Releases. Wir beleuchten dabei, wie wichtig es für Product Owner ist, die Releaseplanung bewusst und vorausschauend zu gestalten. Gerade in agilen Teams, die nach Scrum arbeiten, gibt es oft das Missverständnis, dass am Ende eines jeden Sprints ein Release erfolgen muss, obwohl es doch lediglich heißt, dass das Inkrement potentiell auslieferungsfähig ist (es erfüllt laut Scrum Guide die Definition of Done). Es ist also möglich das Ende eines Sprints und den Zeitpunkt eines Releases voneinander zu entkoppeln. Denn nicht jede potenziell auslieferbare Funktion muss ja sofort live gehen. Ein zentrales Thema ist diesmal die Frage, wann ein Release sinnvoll ist. Product Owner müssen einen klaren Mehrwert für die Nutzer*innen identifizieren , bevor sie den finalen Schritt gehen. Ein Release ist mehr als nur das Bereitstellen von neuen Funktionen. Es erfordert eine detaillierte Planung, um den tatsächlichen Nutzen und Wert zu maximieren. Dabei gilt es, Abhängigkeiten zwischen verschiedenen Teams und Systemen im Auge zu behalten. Ein weiterer wichtiger Punkt, den wir in der Folge ansprechen, ist die Kommunikation während der Releaseplanung. Sowohl intern als auch extern müssen alle Beteiligten – von Entwickler*innen über Support-Teams bis hin zu Stakeholder:innen – auf den gleichen Wissensstand gebracht werden. Oft gibt es während eines Releases eine Downtime, die Nutzer*innen vorher mitgeteilt werden muss. Hierbei sollte der Zeitpunkt für das Release so gewählt werden, dass möglichst wenige Nutzer*innen betroffen sind, wie etwa mitten in der Nacht. Wir diskutieren auch, wie man mit Problemen umgeht, die während eines Releases auftreten können. Es ist wichtig, dass bereits vor dem Release einen klaren Entscheidungsprozess definiert wird, falls unerwartete Schwierigkeiten auftreten. Für große Releases empfiehlt sich außerdem das Konzept des Feature-Toggles, mit dem bestimmte Funktionen gezielt aktiviert oder deaktiviert werden können, um potenzielle Probleme schnell zu identifizieren. Ehrlicherweise sind wir eher Freunde von kontinuierlicher Bereitstellung von Produktveränderungen statt von großen Releases. Aber auch unserer Erfahrung nach gibt es manchmal einfach gute Gründe. Wir würde uns aber wirklich über eure Erfahrungen rund um die Planug großer Releases freuen, denn so können wir besser voneinander lernen. Teilt eure Erfahrungen und Tipps gerne auf unserer Website in den Kommentaren. :-)

Diesmal geht es um ein Thema, das in der digitalen Produktentwicklung noch oft unterschätzt wird: Barrierefreiheit. Mit den Experten Marcel Bertram und Daniel Diener, beide Gründer von A11YPLAN, sprechen wir in dieser Folge über die Bedeutung von Barrierefreiheit in digitalen Produkten und warum sie nicht nur für Menschen mit Behinderungen relevant ist. Barrierefreiheit ist nämlich weit mehr ist als eine rechtliche Notwendigkeit. Barrierefreie Produkte schaffen generell bessere Nutzererlebnisse. Sie sorgen dafür, dass keine Stolpersteine im Weg stehen, wenn Menschen digitale Services nutzen möchten. Egal ob jemand blind ist, vorübergehend eine Einschränkung hat (weil man beispielsweise ein Kind auf einem Arm trägt) oder schlichtweg unter schlechten Lichtverhältnissen arbeitet – ein gutes UX-Design und barrierefreie digitale Produkte machen das Leben leichter. Und das betrifft am Ende uns alle, denn jeder von uns kann in Situationen kommen, in denen eine Website oder App schwerer zugänglich wird. Auch Dinge wie eine langsame Internetverbindung oder schlecht designte mobile Seiten können Hindernisse darstellen und das kennen wir wahrscheinlich alle irgendwo. Barrierefreiheit bedeutet also nicht nur, sich auf spezielle Nutzergruppen zu konzentrieren, sondern das gesamte Produkt so zu gestalten, dass es für jeden einfach nutzbar ist. Seit der Einführung des European Accessibility Act, der ab Juni 2025 gilt, müssen Unternehmen, die digitale Produkte oder Services anbieten, barrierefreie Angebote schaffen – und das nicht nur für neue Websites, sondern auch für bestehende, wenn sie wesentliche Aufrufe erfahren. Doch Marcel und Daniel machen klar: Barrierefreiheit ist nicht nur eine Frage des Gesetzes. Sie ist vielmehr ein klarer Business Case: Gut zugängliche Produkte reduzieren Supportanfragen, erhöhen die Kundenzufriedenheit und steigern den Umsatz. Die Berücksichtigung von Barrierefreiheit in der Produktentwicklung spart nicht nur Kosten, sondern ist auch eine langfristige Investition in die Kundenzufriedenheit. Für Product Owner, die sich bisher noch nicht intensiv mit dem Thema beschäftigt haben, empfehlen Marcel und Daniel, mit einer Bestandsaufnahme zu beginnen. Hier gibt es bereits zahlreiche Tools wie Google Lighthouse oder Deque, die automatisierte Prüfungen durchführen können. Doch das allein reicht nicht: Eine manuelle Überprüfung und echte Nutzertests mit Menschen, die Einschränkungen haben, sind unerlässlich, um sicherzustellen, dass das Produkt wirklich barrierefrei ist. Am Ende der Folge, wie immer, geben die beiden Experten praktische Tipps für den Einstieg in die Welt der Barrierefreiheit. Empathie ist dabei ein zentraler Punkt: Product Owner sollten sich aktiv mit der Frage auseinandersetzen, wie Menschen mit Einschränkungen ihre Produkte nutzen. Eine einfache Übung kann schon sein, auf dem eigenen Smartphone die Barrierefreiheits-Einstellungen zu testen oder Menschen aus dem eigenen Umfeld dabei zu beobachten, wie sie mit den Produkten interagieren. Barrierefreiheit ist keine Herausforderung, die Unternehmen vor sich herschieben sollten. Sie ist ein Schlüssel zu besseren Produkten, zufriedeneren Nutzern und langfristigem Erfolg. Wenn du als Product Owner dein Produkt auf das nächste Level heben willst, führt kein Weg an einer barrierefreien Gestaltung vorbei.

In dieser Folge geht es um ein Thema, das viele Product Owner kennen, aber nicht immer richtig verstehen: Business KPIs. Welche Kennzahlen sind für die Arbeit eines Product Owners tatsächlich relevant und wie beeinflussen sie die Produktentwicklung sowie den Erfolg eines Unternehmens? Gemeinsam sprechen Dominique und Tim über die verschiedenen Metriken, die Product Owner kennen sollten, um fundierte Entscheidungen treffen zu können – von der Conversion Rate bis hin zum Customer Lifetime Value (CLV). Die Frage, die immer wieder aufkommt: Welche KPIs sind für mich als Product Owner wirklich relevant? Business KPIs sind nicht einfach nur eine Kennzahl, sondern ein besonderer Indikator, der hilft, Entscheidungen zu treffen. KPIs sind also mehr als nur Zahlen – sie geben Aufschluss darüber, wie das Produkt genutzt wird und wo Handlungsbedarf besteht. Ein Beispiel ist die Conversion Rate (CR). Sie misst, wie viele Nutzerinnen und Nutzer von einem bestimmten Punkt (z. B. Besuch der Webseite) zu einem gewünschten Endzustand (z. B. Kauf) wechseln. Diese Kennzahl ist nicht nur im Marketing relevant, sondern gibt auch wichtige Einblicke in die Nutzung eines Produkts. Ähnlich verhält es sich mit der Churn Rate, die anzeigt, wie viele Nutzer das Produkt wieder verlassen – ein kritischer Indikator für die langfristige Bindung. Besonders spannend ist die Diskussion um den Umsatz (Revenue) und den Unterschied zwischen Umsatz und Gewinn. Viele Unternehmen konzentrieren sich stark auf steigende Umsatzzahlen, doch wie Tim klarstellt, sind hohe Umsätze natürlich nichts wert, wenn die Kosten explodieren. Hier wird deutlich, wie wichtig es ist, auch auf andere Kennzahlen wie die Customer Acquisition Costs (CAC) zu achten, die die Kosten für die Gewinnung neuer Kunden darstellen. Werden diese Kosten zu hoch, kann das Wachstum langfristig nicht nachhaltig sein. Die Customer Retention Rate (CRR) ist ein weiterer KPI, die für Product Owner von großer Bedeutung ist. Sie zeigt, wie gut es einem Unternehmen gelingt, bestehende Kunden zu halten. Gerade in der digitalen Produktwelt, wo es oft günstiger ist, bestehende Kunden zu binden, anstatt neue zu akquirieren, kann diese Kennzahl entscheidend sein. Besonders spannend ist die Diskussion über den Customer Lifetime Value (CLV). Diese Kennzahl gibt an, wie viel ein Kunde im Laufe seiner gesamten Beziehung mit einem Unternehmen wert ist. Für Product Owner, die Subscription-Modelle oder wiederkehrende Käufe managen, ist dies eine zentrale Größe. Sie hilft dabei, langfristig zu planen und zu verstehen, wie viel ein Unternehmen in die Akquise eines Kunden investieren kann, ohne am Ende Verluste zu machen. Besonders deutlich wird im Gespräch der beiden, wie wichtig es ist, den Zusammenhang zwischen diesen Business KPIs und der täglichen Arbeit als Product Owner zu verstehen. Es reicht nicht aus, nur zu wissen, was ein CLV oder eine Conversion Rate ist – man muss auch in der Lage sein, diese Kennzahlen in konkrete Handlungen umzusetzen, sei es durch die Optimierung von Prozessen oder durch die Anpassung von Produkten. Business KPIs sind für Product Owner also mehr als bloße Zahlen. Sie sind der Kompass, der dabei hilft, den Kurs eines Produkts zu bestimmen und fundierte Entscheidungen zu treffen. Dabei ist es wichtig, die KPIs nicht isoliert zu betrachten, sondern immer im Zusammenhang mit der übergeordneten Strategie des Unternehmens. Product Owner sollten den Mut haben, Fragen zu stellen, wenn sie auf eine unbekannte Begriffe oder Kennzahlen stoßen, und sich die Zeit nehmen, diese zu verstehen. Denn wie Tim und Dominique in der Episode betonen: Oftmals wissen auch die anderen Stakeholder nicht genau, worum es bei einer bestimmten KPI geht – ein klarer Kommunikationsprozess hilft allen Beteiligten, auf dem gleichen Stand zu sein. Hilfreiche ältere Folge des Podcasts passend zum Thema: - Den Wert des Produktes maximieren Wir hoffen, dass du einige neue Impulse zum Thema Business KPI mitnehmen konntest.

Es erscheint gar nicht so leicht, Produktstrategie in die Praxis zu bringen und deren erfolgreiches Wirken zu spüren. In der neuesten Folge des Produktwerker-Podcasts hatten wir das Vergnügen, mit Markus Andrezak, einem Experten in Sachen Produktstrategie, über dieses Thema zu sprechen. Als zweiten Gast hat sich Tim Klein, der Moderator dieser Folge, zudem Oliver Winter, unseren Experten für Strategie und Trainer unserer Produktstrategie-Trainings dazu geholt. Oliver ist diesmal also in der für ihn ungewöhnlichen Rolle als Gast dabei. Tim taucht mit Markus und Oliver tief in in die Frage ein, wie man das Thema Produktstrategie in der Praxis umsetzt, d.h. wie man Produktstrategie in die Praxis bringen und im oft chaotischen Alltag eines Product Owners zum Leben und damit zur Wirkung erwecken kann. Unklarheit als Zeichen fehlender Strategie Markus bringt es auf den Punkt: Wenn Unklarheiten in deinem Team oder deiner Organisation aufkommen, ist dies ein klares Zeichen dafür, dass eine Produktstrategie fehlt oder zumindest nicht klar definiert ist. Doch was tun, wenn du nicht gleich mit großen, überwältigenden strategischen Plänen beginnen möchtest? Hier kommt u.a. die „Challenge-Driven-Strategy“ ins Spiel, ein Konzept, das Markus am Ende des Gesprächs vorstellt. Schritt für Schritt zu mehr Klarheit Statt sofort die gesamte Strategie des Unternehmens auf den Prüfstand zu stellen, empfiehlt Experte Markus Andrezak, Schritt für Schritt vorzugehen. Er rät u.a. dazu, mit dem Produktteam regelmäßige Meetings einzuführen, in denen spezifische Probleme diskutiert und gelöst werden. Der Schlüssel dabei: Diese Treffen sollten immer ein konkretes Ziel haben und nicht in endloses Geplänkel abdriften. Durch diesen kontinuierlichen Prozess wird nicht nur die Zusammenarbeit im Team gestärkt, sondern es entsteht auch langsam, aber sicher eine strategische Ausrichtung des Produkts bzw. Services. Oliver ergänzt Markus’ Vorschlag, indem er betont, wie wichtig es ist, sich als Product Owner auf wenige, aber dafür wesentliche Themen zu konzentrieren. In vielen Teams geht der Fokus verloren, weil zu viele Baustellen gleichzeitig bearbeitet werden. Hierbei hilft es, sich auf die wirklich wichtigen Probleme zu konzentrieren und diese konsequent zu verfolgen. Fazit: Strategie ist kein Hexenwerk Die vielleicht wichtigste Erkenntnis aus dieser Folge? Strategiearbeit muss nicht immer als solche benannt oder formell angegangen werden. Häufig entsteht eine solide Strategie einfach durch die kontinuierliche, fokussierte Lösung von Problemen. Wenn du als Product Ownerin also das Gefühl hast, dass in deinem Produktteam oder deiner Organisation der strategische rote Faden fehlt, dann beginne einfach damit, die größten Unklarheiten aus dem Weg zu räumen – und beobachte, wie sich daraus nach und nach eine klare Produktstrategie entwickelt. Während des Gesprächs wird auch auf die alte, gute Folge mit Florian Meyer verwiesen: Wardley Mapping - Produktstrategie wie ein Schachspiel. Und im Intro natürlich auch auf die beiden super Folgen mit Markus Andrezak: - Warum scheint die Product Owner Rolle so schwer zu sein? (Folge 3 und immer noch eine der meistgehörten Folgen!) - Business- oder Nutzersicht: Welchen Blickwinkel sollte ein PO einnehmen? (neben Markus auch mit Sohrab Salimi - und durch die zwei Experten ausnahmsweise etwas länger als sonst) Wenn du weitere Fragen an Markus Andrezak hat oder mit ihm grundsätzlich in Kontakt kommen möchtest, erreichst du ihn am besten über sein LinkedIn-Profil. Was er ansonsten so treibt und vor allem, was hinter seiner überproduct Academy und dem neuen Angebot "The Strategy Collective" steckt, findest du auf seiner Website ueberproduct.de heraus. Wir hoffen, dass du einige neue Impulse zum Thema 'Produktstrategie in der Praxis' aus den Erfahrungen von Markus und Oliver ableiten konntest. Wenn du deine Tipps und Erfahrungen aus der Praxis teilen möchtest, dann hinterlasse gerne einen Kommentar.

Die ersten Wochen in einer neuen Rolle als Product Owner können überwältigend sein. Als neuer PO steht man vor vielen Herausforderungen, gleichzeitig bietet sich aber unserer Meinung nach auch eine einmalige Chance: den Rahmen für die Produktentwicklung so zu setzen, dass man langfristig Spaß an der Arbeit hat und effektiv agieren kann. In dieser Folge diskutieren Dominique und Oliver vier Schritte, die sich als Orientierungshilfe für die ersten Wochen eignen: 1. KONTEXT VERSTEHEN UND BEZIEHUNGEN AUFBAUEN Bevor man sich in operative Aufgaben stürzt, sollte der Fokus darauf liegen, den Kontext des Produkts und der Organisation zu erfassen. Es geht zu Beginn vor allem darum, relevante Stakeholder kennenzulernen, die Produktvision zu verstehen und die Erwartungen der Beteiligten zu klären. Diese Phase legt das Fundament für alle weiteren Schritte und hilft dabei, spätere Entscheidungen fundiert treffen zu können. 2. RAHMEN FÜR DIE ENTWICKLUNG FESTLEGEN Sobald der Kontext in dem man sich als Product Owner bewegt klarer ist, gilt es, den Rahmen für die Produktentwicklung zu definieren. Dabei spielen sowohl das Aufsetzen eines gut strukturierten Backlogs als auch die Festlegung von Arbeitsweisen im Team eine zentrale Rolle. In diesem Schritt geht es vorangig darum, ein gemeinsames Verständnis zu schaffen, wie gearbeitet und welche Prioritäten gesetzt werden sollen. 3. DELIVERY UND DISCOVERY VEREINEN Ein häufiger Stolperstein in der Produktentwicklung ist die Trennung von kontinuierlicher Lieferung (Product Delivery) und der Entdeckung neuer Optionen und Lösungen (Product Discovery). Beides sollte Hand in Hand gehen. Der Fokus liegt darauf, diese Denkweise im Team zu verankern und sicherzustellen, dass das Product Backlog sowohl kurzfristige Lieferziele als auch explorative Aufgaben berücksichtigt. 4. ZIELE DEFINIEREN UND LANGFRISTIG AUSRICHTEN Darüber hinaus macht es Sinn, konkrete Outcome-Ziele zu definieren. Dominique und Oliver machen in der Episode klar, dass es hier nicht nur um das Setzen von Sprintzielen, sondern vor allem um übergeordnete Ziele wie Produk Goal, Quartalsziele oder KPIs geht. Diese geben allen Beteiligten eine klare Richtung und ermöglichen es, den Fortschritt regelmäßig zu reflektieren und anzupassen. Wichtig ist für die beiden hierbei, solche Ziele nicht zu früh zu formulieren. EIN LANGFRISTIGER ANSATZ Die beschriebenen vier Schritte sind nicht als starre Abfolge zu verstehen, sondern sollten regelmäßig reflektiert und angepasst werden. Auch nach mehreren Monaten lohnt es sich, immer wieder einen Schritt zurückzugehen und zu prüfen, ob der Rahmen noch passt oder ob der Fokus neu justiert werden muss. Am Ende bleibt es entscheidend, dass man als PO nicht nur operativ gefordert ist, sondern sich auch strategische Freiräume schafft, um das Produkt langfristig erfolgreich zu machen. Oliver und Dominique möchten mit diesen Impulsen Product Ownern für die ersten Wochen eine Idee an die Hand geben, wie ihr sinnvoll startet und euren Weg in der Produktentwicklung erfolgreich gestalten könnt.

Guerilla Discovery – das ist ein vielleicht zunächst mal unbekannter oder ungewöhnlicher Begriff. Gemeint ist damit ein unterschwelliger und kontinuierlicher Weg, um Nutzereinblicke zu gewinnen, selbst wenn das Umfeld nicht ideal für tiefergehende Discovery-Prozesse ist. In dieser Episode ist Tobias Morauf, Senior Product Manager bei cosee, zu diesem Thema der Gesprächsgast von Tim. Er gibt spannende Einblicke in seine Art, für mehr Product Discovery zu sorgen - selbst wenn kein Budget bzw. kein expliziter Wille in seinem Produktkontext bzw. Projekt vorhanden ist, nach mehr Product Discovery zu streben. Wie das genau funktioniert und welche praktischen Tipps dabei helfen, beleuchten wir in dieser Folge unseres Podcasts. Unter Guerilla Discovery versteht Tobias ein Vorgehen, bei der Product Discovery nicht aufwendig und formal durchgeführt wird, sondern unterschwellig aber kontinuierlich in den Produktalltag integriert wird. Ziel ist es, trotz knapper Ressourcen und begrenztem Spielraum wertvolle Erkenntnisse zu sammeln. Ein zentraler Gedanke dabei: Discovery braucht oft weniger Zeit und Aufwand, als man denkt. Ein griffiges Beispiel, das Tobias Morauf aus seiner Praxis teilt, zeigt eindrucksvoll, wie dieser Ansatz funktioniert. In einem Projekt ging es um die Migration eines Systems, bei dem es eine klare Feature-Liste von der IT-Abteilung gab. Doch Tobias bemerkte schnell, dass es eine Diskrepanz zwischen den Anforderungen der IT und den tatsächlichen Bedürfnissen des Kundenservice gab. Statt einfach die bestehenden Anforderungen umzusetzen, entschied er sich, den Kundenservice direkt zu beobachten – ganz unauffällig und ohne großes Aufsehen. Durch diese einfache Maßnahme konnte Tobias feststellen, dass einige der ursprünglich geplanten Features überflüssig waren, während andere, wie die Möglichkeit, Kunden zu sperren oder zu anonymisieren, viel wichtiger waren. Diese Erkenntnisse führten nicht nur zu einer besseren Lösung, sondern halfen auch, unnötigen Aufwand zu vermeiden – ganz im Sinne von Jeff Pattons Prinzip: „Maximiere den Outcome, während du den Output minimierst.“ Um Guerilla Discovery erfolgreich in der Praxis umzusetzen, schlägt Tobias einen Ansatz in fünf Schritten vor: Stakeholder überzeugen: Oft gibt es Widerstände, wenn es um zusätzliche Discovery geht. Hier hilft es, mit gezielten Fragen und Annahmen zu arbeiten, statt sofort mit großen Konzepten oder umfangreichen Interviews zu starten. Nutzer verstehen: Der direkte Kontakt zum Nutzer ist essenziell. Wenn dieser nicht möglich ist, helfen kleine, kontinuierliche Beobachtungen und das Hinterfragen bestehender Annahmen. Im kleinen Rahmen experimentieren: Discovery kann auch in kleinen Schritten stattfinden. Es muss nicht immer der große Wurf sein. Auch kurze Beobachtungen oder Gespräche können wertvolle Einsichten liefern. Scope-Creep beachten: Jedes Projekt hat ein Budget, sei es finanziell oder zeitlich. Ein Teil dieses Budgets sollte bewusst für Discovery verwendet werden, da dies langfristig zu besseren Entscheidungen führt und letztlich Ressourcen spart. Den Scrum Master einbinden: Sollte es zu Widerständen im Team kommen, empfiehlt Tobias, den Scrum Master als Verbündeten zu gewinnen. Dieser kann oft helfen, Konflikte zu moderieren und den Fokus auf die Nutzerbedürfnisse zu lenken. Ein zentraler Punkt, den Tobias betont, ist der Mut, den Guerilla Discovery erfordert. Man muss halt aus der eigenen Komfortzone heraustreten und vielleicht auch mal anecken. Doch genau hier liegt der Schlüssel: Wer bereit ist, kleine Schritte zu gehen und immer wieder hinterfragt, kann selbst in einem schwierigen Umfeld wertvolle Erkenntnisse gewinnen. Fazit: Kleine Aktionen, große Wirkung Tobias’ Ansatz zeigt, dass Product Discovery nicht immer aufwendig oder formell sein muss. Durch gezielte, kleine Maßnahmen können auch in einem schwierigen Umfeld wichtige Erkenntnisse gewonnen werden.

Wir haben Dr. Janna Lipenkova mit dem Thema Produktentwicklung von AI Produkten zu Gast. Sie ist eine ausgewiesene und langjährige Expertin auf dem Feld von KI und NLP hat ihren Doktor in Computerlinguistik gemacht. Nachdem sie mehrere Jahre mit KI und NLP sowohl im akademischen als auch in der Industrie gearbeitet hat, hat sie inzwischen zwei eigene Unternehmen in dem Bereich gegründet, die jeweils künstliche Intelligenz nutzen, um modernste Business Intelligence bereitzustellen und helfen, intelligentere Entscheidungen, Strategien und Umsetzungen zu fördern. Zudem arbeitet sie derzeit als Autorin an einem Buch über die Entwicklung von Produkten mit KI, was bald erscheinen wird ("The Art of AI Product Management - a guide for product managers") Im Gespräch mit Tim gibt Janna zunächst ihr Definition von AI Systemen und stellt auf dieser Basis das von ihr entwickelte holistische mentale Modell vor, welches sie für die Produktentwicklung von AI Produkten empfiehlt. Sie folgt bei den drei grundsätzlichen Dimensionen des Produktmanagement (Technologie, UX, Business). Innerhalb dieser Dimensionen zeigt sie dann verschiedene Komponenten, auf, die man besonders bei der Produkte Entwicklung von AI Produkten beachten sollte. Im Bereich Technologie schlägt sie die Bereiche "Data" und "Intelligence" vor. Auf ihre Sicht zu UX von AI Produkten gehen wir in diesem Gespräch nicht so intensiv ein. Sie hat dies in einem tollen Talk beim ProductTank Cologne zuletzt sehr ausführlich getan. In der Dimension Business schlägt sie die besondere Beachtung der beiden Komponenten "Value" und "Opportunity" vor und erläutert jeweils, was sie damit meint. Quellen aus diesem Gespräch: - Artikel "Mental model of an AI system" - Buch von Dr. Janna Lipenkova für Produktmanager: The Art of AI Product Management Wer mit Janna direkt in Kontakt treten möchte oder noch weitere Fragen an sie hat, erreicht sie am besten über ihr LinkedIn Profil. Mehr über ihr Unternehmen Anacode und ihr StartUp EQUINTEL findet ihr im Netz. Wir hoffen, dass Du einige neue Impulse aus den Erfahrungen von Dr. Janna Lipenkova ziehen konntest. Bist Du selber vielleicht schon im Rahmen der Produktentwicklung von AI Produkten aktiv? Was ist dabei für Dich anders? Welche Erfahrungen hast Du selber gemacht und magst darüber berichten? 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. **Folgt uns Produktwerkern auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Diesmal widmen wir uns dem Thema Künstliche Intelligenz (KI) und beleuchten, wie diese die Rolle des Product Owners transformieren kann. Tim und Oliver diskutieren die Chancen und Herausforderungen, die sich durch den Einsatz von KI-Tools im Produktmanagement ergeben. Künstliche Intelligenz ist mehr als nur ein Buzzword. Sie bietet Product Ownern die Möglichkeit, ihre Arbeitsweise zu revolutionieren. KI bietet nicht nur die Chance, Prozesse zu optimieren, sondern auch die Arbeitsweise in der Produktentwicklung grundlegend zu verändern. Dabei ist KI mehr als nur ChatGPT, auch wenn KI häufig mit Anwendungen wie ChatGPT gleichgesetzt wird. Machine Learning, Generative AI und spezialisierte Technologien wie Large Language Models (LLMs) sind nur einige Beispiele für die Bandbreite an Möglichkeiten. Tim erklärt, dass es wichtig ist, über ChatGPT hinauszublicken und andere KI-Anwendungen zu entdecken, die im Produktmanagement nützlich sein können. Im Gespräch werden zahlreiche Beispiele für den Einsatz von KI im Produktmanagement angesprochen: - Stakeholder-Kommunikation: KI kann bei der Erstellung von Release Notes unterstützen und Storytelling durch die Generierung von Bildern und Videos bereichern. - Produktstrategie und -vision: Mit KI-Tools lassen sich komplexe Dokumente wie der Amazon Six-Pager einfacher erstellen, indem die anfängliche Hürde des leeren Blattes überwunden wird. - Wettbewerbsanalyse: KI kann helfen, Nutzerrezensionen des Wettbewerbs auszuwerten, um Differenzierungsvorteile oder neue Feature-Ideen zu entdecken. - Datenanalyse: Mit KI können umfangreiche Datenmengen effizient analysiert werden, um wertvolle Insights zu gewinnen, z. B. durch die Auswertung von Hörstatistiken. Ein zentraler Punkt, den Tim hervorhebt, ist die Notwendigkeit, KI im Dialog zu nutzen. Es reicht nicht aus, nur gute Prompts zu schreiben. Vielmehr sollte KI wie ein Mitarbeiter behandelt werden, der Kontext und klare Anweisungen benötigt. So können KI-Tools effektiver genutzt werden und wertvolle Unterstützung bieten. Beim Einsatz von KI-Tools müssen Datenschutz und ethische Überlegungen berücksichtigt werden. Product Owner sollten sich aktiv dafür einsetzen, KI-Tools im Unternehmen nutzen zu dürfen, dabei jedoch stets die datenschutzrechtlichen Rahmenbedingungen beachten müssen. Abschließend zeigt die bisherige Erfahrung, dass KI-Tools die Arbeit von Product Ownern bereichern können. Es geht darum, KI als unterstützenden Assistenten zu sehen, der hilft, Aufgaben effizienter zu gestalten, ohne die menschliche Rolle zu ersetzen. Wenn ihr mehr hören wollt, empfehlen wir euch anschließend die Folge "Wie No-Code Tools Produktteams helfen". Ein paar nützliche Tipps zum Einsatz von KI im Sprint Review gab es in der Folge "Was macht ein gutes Sprint Review aus?". Tim hatte auch bereits im Januar 2023 ein "Interview" mit ChatGPT zur PO Rolle geführt - diese Episode hieß "Was weiß künstliche Intelligenz schon über Produktentwicklung?" Wie sieht es bei euch aus? Nutzt ihr schon KI-Tools in eurer Arbeit als Product Owner, Product Manager und Product Leads? Wir sind gespannt von euren Erfahrungen zu hören. Gerne hier als Kommentar, auf unserer LinkedIn-Page oder direkt als Mail an info@produktwerker.de. Wie sieht es bei euch aus? Nutzt ihr schon KI-Tools in eurer Arbeit als Product Owner, Product Manager und Product Leads? Wir sind gespannt von euren Erfahrungen zu hören. Wir freuen uns, wenn du deine Meinung zu KI und deine Einschätzung für KI in der Produktentwicklung mit uns in einem Kommentar des Blog-Artikels (https://produktwerker.de/ai-als-wingman-fuer-product-owner/) teilst oder auf unserer Produktwerker LinkedIn-Seite (https://www.linkedin.com/company/produktwerker).

Tim, Dominique und Oliver haben im Product Owner Podcast von Die Produktwerker schon in der einen oder anderen Folge über die Notwendigkeit einer Produkt Vision gesprochen. In dieser Episode geht es aber primär um die UX Vision bzw. das UX Vision Canvas, welches Dominique Winter in den letzten Jahren entwickelt und mit dem er in vielen Organisationen sehr erfolgreich gearbeitet hat. Das ist Grund genug, dass sich Oliver mit Dominique in der aktuellen Episode über das Thema ausführlich unterhalten haben. Die beiden starten in das Gespräch mit der Frage, warum es sich als Produktentwicklungsteam lohnen kann, auch eine UX Vision zu erarbeiten. Dominique teilt in der Diskussion seine reichhaltigen Erfahrungen, wie man an die Erstellung dieses Artefaktes herangehen sollte. Dabei kann das UX Vision Canvas bei vielen Fragestellungen und Perspektivwechsel gut unterstützen. Selbstverständlich ist das Befüllen der Felder des UX Vision Canvas kein Selbstzweck, sondern spannend wird es erst, wenn man in der täglichen Arbeit als Product Owner auch mit der abgestimmten UX Vision arbeitet. Auch hierzu teilt Dominique wieder viele Learnings aus der Praxis. Er hat einige Beispiele dabei, wie ich diese UX Vision nutzen kann und welche Herausforderungen dabei zu beachten sind. Wie jede Podcastfolge schließen die Beiden mit Tipps & Tricks ab. Die beiden starten in das Gespräch mit der Frage, warum es sich lohnen kann, auch eine UX Vision zu erarbeiten. Dominique teilt in der Diskussion seine reichhaltigen Erfahrungen, wie man an die Entwicklung herangehen sollte. Dabei kann das UX Vision Canvas gut unterstützen. Natürlich ist das Ausfüllen des UX Vision Canvas kein Selbstzweck, sondern spannend wird es erst, wenn man in der täglichen Arbeit als Product Owner auch mit der UX Vision arbeitet. Auch hierzu teilt Dominique wieder viele Learnings aus der Praxis, wie ich diese UX Vision nutzen kann und welche Herausforderungen dabei zu beachten sind. Wie jede Podcastfolge schließen die Beiden mit Tipps & Tricks ab.

Schon im Scrum Guide wird klar formuliert, dass Scrum Master in bestimmten Fragestellungen ihre Product Owner unterstützen sollen. Als ausgewiesenen Experten für die Scrum Master Rolle haben wir uns daher erneut Alexander Kylburg eingeladen. Er ist schon mindestens 15 Jahre in der agilen Szene und vor allem im Rheinland ein sehr engagiertes Mitglied der Agile Community. So hat er den Kölner Scrumtisch nahezu von Tag 1 begleitet und die regelmäßige Agile Cologne als bedeutende agile Konferenz zusammen mit anderen vor über 10 Jahren ins Leben gerufen. Tim bespricht mit Alexander zunächst mal, wie er die Verantwortlichkeit von Scrum Mastern versteht und wie sie selbst ihre Scrum Master weiterbilden. Natürlich auch, wie man als Scrum Master überhaupt in die Product Owner Themen reinkommen kann. Spannend ist seine Einschätzung, wie gut bzw. intensiv Scrum Master heutzutage ihre Product Owner unterstützen. Was muss ein Scrum Master dafür wissen, um eine wertvolle methodische Unterstützung bzw. entsprechendes Coaching leisten zu können? Aber de beiden kommen im Gespräch auch an den üblichen Problemen vorbei: Was ist, wenn sich der der Product Owner vielleicht gar nicht helfen lassen will bzw. faktisch der Scrum Master keinen entsprechenden Zugang zum Product Owner findet? Genauso kann sich das Problem auch andersrum darstellen: der Product Owner "zieht" den Scrum Master in inhaltliche und operative Arbeit hinein und missachtet dabei die eigentliche Rolle des Scrum Masters. Darüber hinaus gibt es in dieser Folge auch praktische Tipps, wie sich Scrum Master das entsprechende Wissen aneignen können und auf Augenhöhe bleiben können. Das von Alexander Kylburg mehrfach erwähnte "Agile Coaching Growth Wheel" ist in Toolbox (empfehlenswert!) von paragraph eins gut und detailliert beschrieben: paragraph1.de/toolbox/das-agile-coaching-growth-wheel Das Toleranz Modell und das am Ende erwähnte Kartenspiel "Toleranz Poker" könnt ihr dort ebenfalls finden. Auf folgende ältere Folgen wird im Laufe des Gesprächs verwiesen: - Konflikte zwischen Scrum Master und Product Owner (mit Gast Alexander Kylburg - Dein Freund der Scrum Master Wer mit Alexander Kylburg oder seiner Firma paragraph eins (paragraph1.de) in Kontakt treten möchte, erreicht ihn am Besten auf seinem LinkedIn-Profil. Übrigens ist paragraph eins ein sehr geschätzter Kooperationspartner von uns. Wir hoffen, dass du mit dieser Folge wertvolle Ideen bekommen hast, wie du als Scrum Master oder Product Owner ein gutes Sprint Review gestalten kannst. Welche Erfahrungen hast Du selber gemacht und magst darüber berichten? 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. **Folgt uns Produktwerkern auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Obwohl der Scrum Guide definiert, dass der Product Owner nur eine Person und kein Gremium sein soll, sehen wir in der Realität vieler Organisationen, dass die Product Ownership auf mehrere Personen aufgeteilt wird. Tim und Oliver analysieren in dieser Folge unterschiedliche Ausprägungen von Shared Product Ownership. Welche Herausforderungen entstehen, welche Vorteile hat ein solches Szenario und welche Nachteile muss ich in Kauf nehmen? In ihrem Gespräch kommen die beiden zu Schluss, dass es einige Kontexte gibt, in denen Shared Product Ownership sinnvoll sein kann, unabhängig davon was der Scrum Guide definiert. Natürlich schließen Oliver und Tim auch diese Folge wieder mit praktischen Tipps und Tricks ab, die Dir bei geteilter Verantwortung helfen können. Links auf in der Folge erwähnte Quellen: - Talk von Markus Andrezak - Roman Pichlers Blogpost - Podcastfolge: Ein Scrum Team, zwei POs - geht das?

Wie läuft eigentlich ein richtig gutes Sprint Review? Mit unserem Gast Jan Lensing bespricht Tim dieses Thema nun auf Basis der konkreten Praxiserfahrungen von Jan. Jan ist Scrum Master bei der Firma comnovo - ein spannendes Industrieunternehmen mit Hardware- und Software-Produkten rund um die Entwicklung von Assistenzsystemen für die Intralogistik. Also sehr vereinfacht gesagt, damit man nicht von Gabelstaplern (in allen möglichen Dimensionen) überfahren wird. In diesem Kontext wird nach Scrum gearbeitet und über einen SAFe-Ansatz skaliert. Wir haben uns natürlich schon in früheren Folgen unseres Podcast um das Sprint Review gekümmert. Dennoch geben gerade die vielen Praxisbeispiele nochmal richtig wertvolle Impulse für dieses Scrum Event. Im Gespräch wird sowohl die gute Vorbereitung als auch die gelungene Durchführung eines Reviews besprochen. Zur Vorbereitung gilt natürlich schon die Frage, wann und wie lange man es durchführt sowie wie man die wichtigsten Stakeholder am besten einlädt. Bei der Verbesserung ihrer Sprint Reviews hat Jan Lensing tolle Ideen mitgebracht, die er mit seinen Teams bereits ausprobiert. Auf folgende ältere Folgen wir im Laufe des Gesprächs verwiesen: - Als Product Owner im Sprint Review - Sprint Review ohne Stakeholder - Wer nimmt User Stories ab? - Plattform Team Product Owner: eine besondere Herausforderung Hier noch der Link zum Video "Staplerfahrer Klaus" - ein echter Evergreen aus dem Jahr 2000 und damals vermutlich eines der ersten Videos, was richtig viral ging. Wer mit Jan Lensing in Kontakt treten möchte, um evtl. noch weitere Rückfragen zu klären, erreicht ihn am Besten auf seinem LinkedIn-Profil. Wir hoffen, dass du mit dieser Folge wertvolle Ideen bekommen hast, wie du als Scrum Master oder Product Owner ein gutes Sprint Review gestalten kannst. Welche Erfahrungen hast Du selber gemacht und magst darüber berichten? 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. **Folgt uns Produktwerkern auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

In dieser Folge sprechen Dominique und Oliver über Triggerpunkte gesprochen – sowohl unsere persönlichen als auch diejenigen, die wir in Produktorganisationen erleben. Diese Punkte können starke emotionale Reaktionen und Konflikte auslösen und sind oft tief in den Strukturen und Spannungen einer Organisation verwurzelt. In der Episode möchten wir die wichtigsten Erkenntnisse und einige Strategien vorstellen, wie man in Produktorganisationen diese Triggerpunkte erkennen und damit umgehen kann. Triggerpunkte sind Themen oder Ereignisse, die intensive emotionale Reaktionen hervorrufen. Sie können in vielen verschiedenen Kontexten auftreten, von gesellschaftlichen Themen wie Gender-Sternchen bis hin zu spezifischen organisatorischen Veränderungen. In der Arbeitswelt können Triggerpunkte zu Konflikten und Spannungen führen, die die Zusammenarbeit und Produktivität beeinträchtigen. Typische Triggerpunkte in Produktorganisationen Änderungen in der Produktstrategie Eine plötzliche Änderung der Produktstrategie, die nicht ausreichend kommuniziert oder begründet wird, kann bei den Betroffenen zu Unzufriedenheit und Widerstand führen. Produktverantwortliche müssen oft Entscheidungen umsetzen, die sie nicht nachvollziehen können, was das Gefühl der Ungerechtigkeit verstärken kann. Neue Tools und Prozesse Die Einführung neuer Tools oder Prozesse ohne Rücksprache mit dem Team kann starke negative Reaktionen auslösen. Dies gilt insbesondere, wenn die neuen Werkzeuge die bisherigen Arbeitsweisen erheblich verändern und zusätzliche Belastungen verursachen. Organisatorische Veränderungen Veränderungen in der Teamzusammensetzung oder organisatorische Umstrukturierungen können bestehende Spannungen verstärken. Wenn beliebte Teammitglieder versetzt oder entlassen werden, kann dies das Vertrauen und die Moral im Team beeinträchtigen. Mangelnde Kommunikation und Einbeziehung Eine unzureichende Kommunikation seitens der Führungsebene und das Gefühl, nicht in Entscheidungsprozesse einbezogen zu werden, können starke emotionale Reaktionen hervorrufen. Oft fühlen sich Mitarbeiter ungerecht behandelt oder nicht wertgeschätzt. Ursachen und Auslöser von Triggerpunkten Die Ursachen für Triggerpunkte liegen oft in tief verwurzelten Überzeugungen und Werten. Diese können durch mangelnde Transparenz, unzureichende Kommunikation oder das Fehlen von Ressourcen und Unterstützung verstärkt werden. Ein Gefühl der Ungerechtigkeit oder ungleiche Behandlung kann ebenfalls ein starker Auslöser sein. Strategien zum Umgang mit Triggerpunkten Offene und transparente Kommunikation fördern Eine klare und transparente Kommunikation ist entscheidend, um Triggerpunkte zu vermeiden oder zu entschärfen. Indem man die Gründe hinter Entscheidungen erläutert und die Betroffenen frühzeitig einbezieht, kann man Missverständnisse und Widerstände reduzieren. Vertrauen aufbauen Vertrauen ist die Grundlage für jede erfolgreiche Zusammenarbeit. Führungskräfte sollten durch ihr Verhalten Vertrauen schaffen, indem sie sich öffnen, Schwächen zeigen und die Meinungen und Bedürfnisse der Mitarbeiter ernst nehmen. Ressourcen bereitstellen Um mit neuen Herausforderungen umzugehen, benötigen Teams ausreichende Ressourcen und Unterstützung. Schulungen und Weiterbildungen können helfen, die Kompetenzen zu erweitern und die Arbeitsbelastung zu bewältigen. Kulturelle Veränderungen anstoßen Eine positive Unternehmenskultur, die auf Vertrauen, Offenheit und Zusammenarbeit basiert, kann langfristig dazu beitragen, Triggerpunkte zu minimieren. Führungskräfte sollten diese Kultur vorleben und kontinuierlich fördern. Sprache bewusst wählen Die Wahl der Worte kann einen großen Unterschied machen. Anstatt Begriffe zu verwenden, die negative Assoziationen hervorrufen, sollte man neutralere oder positivere Formulierungen wählen, um Widerstände zu vermeiden.

Wir Produktwerker werden immer häufiger als Impulsgeber für interne Veranstaltungen angefragt. Und so gerne wir solche Mandate auch annehmen, fragen wir uns, wo denn die ganzen Product Owner bei den vielen Konferenzen, Meetups oder Online-Webinaren eigentlich sind. Daher appellieren Tim und Oliver in der aktuellen Podcastfolge an alle POs: Geht raus aus eurem Gebäude, holt euch Hilfe und seid keine Einzelkämpfer. Zu Beginn der Episode teilen die Beiden ihre persönlichen Beobachtungen von Konferenzen, aber auch die Beteiligung an aktuellen Diskussionen beispielsweise auf LinkedIn oder X. Tim und Oliver kommen zu dem Schluss, dass meist mehr Scrum Master & Agile Coaches solche Angeboten annehmen als Product Owner, obwohl es theoretisch gleich viele von ihnen geben müsste. Was sind mögliche Gründe, dass Product Owner nicht so oft derartige Angebote wahrnehmen. Warum suchen sie wenig Hilfe von anderen Product Ownern? Ist der eigenen Workload zu groß, die Energie zu gering oder ist es der Glaube, dass der Kontext, in denen andere POs arbeiten zu unterschiedlich ist als dass man selber etwas lernen kann? Auf alle Fälle entstehen so einige Probleme, die Tim und Oliver auch diskutieren. Und wie in jeder Podcastfolge haben die Beiden aber auch zahlreiche Ideen mitgebracht, falls man an der eigenen Situation etwas verändern möchte. Wir immer schließt die Episode mit einigen Tipps und Tricks ab, die Du sofort umsetzen kannst.

Was sind Pirate Metrics? Das auch als das AARRR-Modell bekannte Set von Metriken hat vor allem im Bereich des Growth Marketing starke Verbreitung und Bekanntheit. Unser Gast Timothy Krechel ist Head of Digital Product Consulting bei Qvest Digital und nutzt die Pirate Metrics auch gerne in der Arbeit von Produktmanagern. Zunächst ergründen Tim und Timothy im Gespräch, was das Akronym "AARRR" bedeutet und woher der Begriff "Pirate Metrics" kommt. Ja - tatsächlich ist hier die Analogie zum furchteinflößenden Ruf von Piraten der profane Grund. Die Abkürzung AARRR steht hingegen für die fünf wichtigsten Funnel-Schritte, auf die sich jedes Unternehmen konzentrieren sollte: „Acquisition“ (Akquisition), „Activation“ (Aktivierung), „Revenue“ (Umsatz), „Retention“ (Kundentreue) und „Referral“ (Empfehlungen). Das Modell hilft, die Customer Journey und die bevorzugten Kanäle der Nutzer besser zu verstehen und in (strategischen) Diskussionen entsprechende Klarheit herzustellen. Außerdem ermöglichen diese sogenannten "Pirate Metrics", umsetzbare Ziele je Funnel-Step festzulegen. Timothy Krechel erklärt dann jeden Schritt des AARRR-Modells im Detail und zusammen mit Tim wird das Verständnis anhand von Beispielen geschärft. Natürlich gibt es noch andere Funnel-Ansätze als die Pirate Metrics. Aber gerade für transaktionsbasierte Geschäftsmodelle ist eine solche Funnel-Darstellung hilfreich. Tim zeigt auch Beispiele aus dem Produktportfolio der Produktwerker zu den einzelnen Steps auf. Spannend wird dann die Frage, wie das AARRR-Modell konkret zu nutzen ist und vor allem, wie es mir als Product Owner helfen kann. Hier gibt der Gast Timothy Krechel wertvolle Impulse, wie die Pirate Metrics in den Alltag als Product Owner integriert werden können. Abschließend zeigt Timothy aber auch die Schwächen der Pirate Metrics auf, um ein rundes Bild zu zeichnen. Passende Podcast-Folgen rund um das Thema Customer Journey: - Mit Customer Journey Maps arbeiten - Customer Journey Management im Konzern - ein Erfahrungsbericht Wenn ihr weitere Fragen an Timothy habt oder mit ihm Kontakt aufnehmen möchtet, vernetzt euch am besten via LinkedIn mit ihm oder schreibt an hello@timothy.de. Weiteren wertvollen Content von und mit Timothy Krechel gibt es in den Product Lunches von Qvest Digital. Kanntest du die Pirate Metrics? Und nutzt ihr sie auch in der Praxis bei euch?Wie bindest du dann das AARRR-Modell in deine Arbeit als Product Owner ein? 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. **Folgt uns Produktwerkern auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Es ist Sommer und der Product Owner macht Urlaub - echt jetzt? Geht das überhaupt? Immerhin ist die Rolle ja ohne dedizierte Stellvertretung in Scrum ausgelegt. Die Frage stellen sich jetzt zu Beginn der Urlaubszeit im Sommer sicherlich wieder einige Teams und Product Owner oft auch selbst. Dominique und Tim diskutieren darüber und sind sich grundsätzlich einig: dass ein Product Owner Urlaub macht ist unerlässlich, um sich zu erholen und wieder Kraft zu tanken. Die Vorstellung, dass ein Product Owner unersetzlich seien, kann problematisch sein. Mit den richtigen Maßnahmen lassen sich Probleme während der Abwesenheit jedoch minimieren. Denn ohne gute Vorbereitung und eine vernünftige Übergabe kann es sonst wirklich problematisch für den Erfolg der Produktentwicklung werden. Eine gute Vorbereitung ist besonders entscheidend. Wichtig ist, dass alle relevanten Prozesse und Entscheidungen dokumentiert sind. Das Team sollte frühzeitig über den geplanten Urlaub informiert und Aufgaben sowie Verantwortlichkeiten klar delegiert werden. Ein gründlicher Wissenstransfer sorgt dafür, dass die Vertretung vom Product Owner Zugriff auf alle notwendigen Dokumente und Ressourcen hat. Zudem sollte das Product Backlog gepflegt und Sprintziele klar definiert werden, um Transparenz über den Status der Produktentwicklung zu gewährleisten. Während der Abwesenheit des POs muss die Kommunikation mit dem Team und den Stakeholdern klar geregelt sein. Es sollte klar sein, wer die Ansprechpartnerin ist und wie Eskalationswege aussehen. Die Erreichbarkeit des POs im Notfall sollte ebenfalls geklärt sein. Manchmal kann das Sinn machen. Nach dem Urlaub ist es wichtig, die Aufgaben und Verantwortlichkeiten schrittweise wieder zu übernehmen und sich über den aktuellen Stand zu informieren. Die während der Abwesenheit getroffenen Entscheidungen sollten explizit besprochen werden. In der Retrospektive kann besprochen werden, wie sich die Abwesenheit auf das Team ausgewirkt hat und welche Verbesserungen für die Zukunft vorgenommen werden können. Tim und Dominique empfehlen, sich auch auf unvorhergesehene Abwesenheiten vorzubereiten und nach dem Urlaub nicht sofort wieder zu 100% in den Arbeitsalltag einzusteigen. Eine gut vorbereitete Abwesenheit ist nicht nur möglich, sondern auch wichtig für die nachhaltige Entwicklung des Produkts und die eigene Erholung. In der Episode wird auch auf diese älteren Podcast-Folgen Bezug genommen: - POEM - Product Ownership Evolution Model - Dein Freund der Scrum Master Wie geht ihr mit dem Thema des Urlaubs vom Product Owner um? Vielleicht hast du ja auch Tipps für andere Product Owner, wie ihr das so löst und welche Erfahrungen ihr da schon gemacht habt? 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. **Folgt uns Produktwerkern auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

In dieser Folge unseres Podcasts dreht sich alles um das wichtige Thema der Nachhaltigkeit in der digitalen Produktentwicklung. Unser Gast, Thorsten Jonas, Experte für digitale Nachhaltigkeit und Gründer des Sustainable UX Network, teilt seine umfangreiche Erfahrung und wertvolle Einblicke mit uns. Thorsten erklärt, was digitale Nachhaltigkeit wirklich bedeutet, und zeigt auf, wie Unternehmen durch gezielte Maßnahmen ihre digitalen Produkte umweltfreundlicher gestalten können. Er spricht über die Herausforderungen, denen Organisationen begegnen, wenn sie nachhaltige Praktiken einführen, und wie diese überwunden werden können. Wir erfahren, welche Tools und Methoden Thorsten und sein Team im Sustainable UX Network nutzen, um Nachhaltigkeit in den gesamten Produktdesignprozess zu integrieren. Thorsten gibt zudem praktische Tipps, wie man mit einfachen Schritten beginnen kann, digitale Produkte nachhaltiger zu machen. Ein besonderes Highlight der Folge sind Thorstens konkrete Handlungsempfehlungen für sofort umsetzbare Maßnahmen, um den CO2-Fußabdruck digitaler Produkte zu reduzieren und langfristig nachhaltigere Prozesse zu etablieren. Hört rein und lasst euch inspirieren, wie ihr eure digitale Produktentwicklung nachhaltig gestalten könnt!

Als Product Owner treffen wir ständig Entscheidungen. Priorisierung des Product Backlogs, Festlegen eines Sprintziels, das nächste Ziel auf der Product Roadmap oder die vielen anderen, kleinen Dinge im Alltag. Warum das Entscheiden eher einem Pokerspiel als einem Schachspiel gleicht und Product Owner wie Pokerspieler denken sollten, darüber sprechen Tim und Oliver in dieser Episode. Die zwei Faktoren, die das Ergebnis einer Entscheidung entscheiden, sind die Qualität des Entscheidungsprozesses und Glück. Diese These formuliert Annie Duke, professionelle amerikanische Pokerspieler in ihrem Buch “Thinking in Bets”. Dieses in Wetten denken ist ein gutes Gedankenmodell für Product Owner. Denn bei jeder Entscheidung existiert ein gewisses Maß an Unsicherheit. Wichtig ist zu wissen, wie hoch meine Gewinnchancen sind und was ich einsetzen muss, wenn ich diese Wette eingehe. So kann ich wie im Poker den Anteil guter Wetten erhöhen und erfolgreicher sein. Der zweite, auch im Produktkontext hilfreiche Gedanke ist, nicht vom Ergebnis einer Entscheidung auf die Qualität der Entscheidung zu schließen. Dies folgt aus der Komponente Glück, denn selbst wenn ich zu 95% sicher bin, können die 5% doch eintreten. Wenn ich als Product Owner wie ein Pokerspieler mich nicht zu sehr von den Ergebnissen beeinflussen lasse, dann werde ich beispielsweise selbstbewusster auftreten und meine Entscheidung nachträglich den Stakeholdern begründen können.

Wie entwickelt man eigentlich Produkte, die Kunden wirklich lieben? Diese Herausforderung kennen viele von uns. Unser Gesprächspartner ist diesmal Ulf Schubert, ein erfahrener UX-Experte, der uns wertvolle Einblicke und praktische Tipps dazu geben kann. Ulf weißt direkt am Anfangdarauf hin, dass es nicht genügt, ein Produkt nur optisch ansprechend zu gestalten. Der Schlüssel liegt darin, die verschiedenen Anforderungen und Erwartungen der Nutzenden zu verstehen und auszubalancieren. Es geht darum, ein holistisches Design zu schaffen, das sowohl visuell als auch interaktiv ansprechend ist und die Bedürfnisse der Nutzer erfüllt. Es ist außerdem schwer, sich allein durch technischen Fortschritt zu differenzieren. Stattdessen sollten Unternehmen schnell die Bedürfnisse ihrer Kund:innen erkennen und diese besser als die Konkurrenz erfüllen. Der Fokus sollte darauf liegen, die Erwartungen der Kund:innen zu übertreffen, um Begeisterung zu erzeugen und dadurch positive Mundpropaganda zu fördern. Ein zentraler Punkt in dem Gespräch war die Methodik. Ulf betonte, dass es nicht die Methode an sich ist, die entscheidend ist, sondern wie flexibel und spielerisch man mit ihr umgeht. Er hob das Konzept der Product Discovery hervor, bei dem vier Fragen im Mittelpunkt stehen: Welche Bedürfnisse gibt es? Wie müssen wir sie erfüllen? Können wir das technisch umsetzen? Und erreicht das unsere geschäftlichen Ziele? Für erfolgreiches Produktmanagement ist es essentiell, kontinuierlich von den Kunden zu lernen und sich anzupassen. Dies erfordert sowohl eine hohe Kundenkompetenz als auch einen datenbasierten Ansatz. Teams sollten regelmäßig Feedback einholen und Nutzungsdaten analysieren, um schnell auf Veränderungen reagieren zu können. Empathie spielt dabei eine zentrale Rolle. Ulf betonte, wie wichtig es ist, dass Teams die Bedürfnisse und Erwartungen der Nutzer verstehen und sich in deren Lage versetzen können. Dies kann durch direkte Interaktion mit den Kunden, etwa durch Besuche vor Ort oder Teilnahme an Nutzertests, erreicht werden. Zum Abschluss des Gesprächs gab Ulf zwei wesentliche Tipps: - Nehmt euch Zeit, Empathie für die Kund:innen zu entwickeln. Hört zu und beobachtet sie genau, um deren Bedürfnisse und Erwartungen zu verstehen. - Erweitert eure Perspektive und betrachtet das Produktdesign ganzheitlich. Eine gute Lösung ist immer ein Zusammenspiel verschiedener Aspekte – technischer, fachlicher und gestalterischer Natur. Durch diese Ansätze können Produkte entwickelt werden, die nicht nur funktional und ansprechend sind, sondern die Kund:innen wirklich lieben. Ein Produkt, das Bedürfnisse erfüllt und Erwartungen übertrifft, schafft Begeisterung und langfristige Zufriedenheit.

Zack! Gerade wurde dir mitgeteilt, dass du nun plötzlich Product Owner sein sollst. Puh, was heißt das und was wird ab jetzt von mir erwartet? Diese Situation kommt gar nicht so selten vor - nach unserer Beobachtung vor allem in größeren Unternehmen. Oliver und Tim beleuchten die verschiedenen Kontexte und Situationen in denen dies geschehen kann und erklären damit ein Stück weit, wie es dazu kommt. Ihre Beobachtungen basieren auf ihrer langjährigen Erfahrungen in agilen Transformationen sowie auch aus ihrer Mentoring- und Trainingspraxis bei der Begleitung von (neuen) Product Ownerinnen und Produktorganisationen im Umbruch. Vor allem liefern die beiden aber Empfehlungen und Tipps, wie man selbst mit so einer Herausforderung umgehen kann. Wie kann ich diese neue Rolle dabei vielleicht sogar aktiv gestalten? Vieles hängt dabei daran, mehr Rollenklarheit herzustellen (Stichwort: Erwartungsmanagement). Genauso wichtig ist aber auch, die mögliche eigene Unsicherheit offen anzusprechen und sich bei "Umlernen" von seinem direkten Teamumfeld helfen zu lassen. Auf diese Podcast-Folgen wird im Gespräch verwiesen: - Welche Aufgaben gehören zur Product Owner Rolle? - Stellenausschreibungen für Product Owner - WTF? - Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner - Plattform Team Product Owner: eine besondere Herausforderung - Vom Projektleiter oder Teamleiter zum Product Owner - POEM - Product Ownership Evolution Model - Sei dein eigenes Produkt! – Weiterentwicklung für Product Owner - Nutze Story Mapping, um mit Stakeholdern über Outcome zu sprechen Weitere empfohlene Quellen zur Herausforderung plötzlich Product Owner zu sein: - Video "Story-Mapping" im Produktwerker-YouTube-Kanal - Matt LeMay: Product Management in Practice (zu den "CORE Skills") - Beispielhafter Artikel zur “How to Work with Me” Idee mit weiterführenden Links und Templates: https://www.linkedin.com/pulse/how-work-me-document-senia-maymin/ Kennst du die Situation, plötzlich Product Owner zu sein? Gab's oder gibt es das in deinem Umfeld vielleicht auch? Wie hast du das empfunden oder was hast du beobachtet? Vielleicht hast du ja auch Tipps für andere Product Owner? 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. **Folgt uns Produktwerkern auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

In dieser Podcast-Episode tauchen Dominique und Oliver tief in das Konzept des "The Decision Stack" ein und diskutieren, welche Erkenntnisse ein Product Owner aus dem mentalen Model von Martin Eriksson ziehen kann. Das Thema, was die meisten Product Owner, mit denen wir als Produktwerker arbeiten dürfen, tagtäglich beschäftigt, ist die Priorisierung der Anforderungen und die Sortierung der Product Backlog Items. Unserer Erfahrung nach handelt es sich bei dieser Herausforderungen gar nicht um das eigentliche Problem sondern ist lediglich das Symptom für das Fehlen einer angestimmten, logischen Vorgehensweise auf visionärer, strategischer und taktischer Ebene. Oliver und Dominique teilen daher zu Begin der Folge unterschiedliche Situationen aus ihrer eigenen Praxis. Für die Lösung dieser Herausforderungen bietet der Decision Stack ein strukturiertes aber dennoch einfaches mentales Model an, um mit komplexen Entscheidungen auf allen Flughöhen umgehen zu können. Oliver erklärt die einzelnen Elemente, Product Vision, Product Strategy, Objectives, Opportunities und Tasks und wie diese zusammenhängen. Im nächsten Schritt konkretisieren die beiden das Model für den Kontext eines Produkt Owners. Dominique und Oliver überlegen, wann und wie wir als Product Owner den Decision Stack effektiv in der täglichen Arbeit einsetzen können, um zielgerichteter agile unser Produkt weiterzuentwickeln. Wie immer schließt die Folge mit praktischen Tipps und Tricks ab. Martin Eriksson hat auf seiner Webseite eine ganze Reihe von Informationen, Slides und Videos zum Decision Stack geteilt. Der Gründer der Mind the Product Bewegung kündigt auch ein eigens Buch zu dem Thema an. Wir wünschen Dir wie immer vielen neue Impulse für Deine eigene Arbeit als Product Owner.

Immer häufiger trifft man auf Product Owner von einem Plattform Team. Schnell kommen dann die Fragen auf, ob und wie die Ideen eines klassischen Scrum Product Owners anwendbar sind. Was ist das Produkt? Was sind in diesem Fall die Kunden bzw. besser gesagt die Nutzer? Ganz offensichtlich ergeben sich aus solchen Rahmenbedingungen eine Reihe von ganz speziellen Herausforderungen. Daher nehmen sich Dominique Winter und Tim Klein in dieser Folge des Themas an. Entsprechend klären sich zunächst mal die Frage, was genau hinter dem Begriff des Plattform Teams steckt und wie es sich von den Experience Teams abgrenzt. Unter den besonderen Herausforderungen heben sie hervor, sich nicht in die Ecke eines internen Dienstleisters drängen zu lassen. Auch wenn man als ein solcher Product Owner keinen externen Marktzugang hat, ist der Aufbau eines echten Problemverständnisses der (internen) Nutzer aus den sog. Experience Teams sehr wichtig. Auch Stakeholder Management bekommt als Product Owner eines Plattform Teams eine besondere Bedeutung. In der Regel hat man ja mehrere andere Teams, dem eine solche Plattform zur Nutzung bereitgestellt wird. Schnell können dadurch unterschiedliche oder auch widersprüchliche Anforderungen herangetragen werden. Die eigene Plattform muss aber gemäß der eigenen Produktvision in eine geplante Richtung entwickelt werden. Die Gefahr, es jedem internen Stakeholder Recht zu machen und damit mit der Plattform zum Spielball der Kräfte zu werden, ist ansonsten sehr hoch. Es geht also letztlich darum, den Wert der eigenen Plattform als Lösung für die Probleme der Experience Teams im Blick zu behalten und die Plattform Lösung als gestaltende Product Ownerin zu führen. In dieser Folge wird auf diese Quellen referenziert: - Podcast-Folge: Vom Entwickler zum Product Owner - Buch: Manuel Pais und Matthew Skelton: "Team Topologies: Organizing Business and Technology Teams for Fast Flow" - Buch: Marty Cagan: "EMPOWERED" Bist du evtl. selber auch Product Owner in einem Plattform Team oder arbeitest du in bzw. mit einer solchen Teamkonstellation? Welche Herausforderungen erlebst du ähnlich, welche weiteren siehst du noch? Und hast du ergänzende Tipps für die Situation auf Basis deiner eigenen Erfahrung? 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. **Folgt uns Produktwerkern auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

In dieser Podcast-Folge widmen wir uns der Herausforderung, OKR in der Praxis sinnvoll einzusetzen. Tim hat dafür die Expertin und Autorin Christina Lange zu Gast. Sie ist freiberuflich OKR Coach und hauptberuflich Head of Agile und Lead Digital Academy bei der METRO.digital. Christina erlebt also seit vielen Jahren OKR in der Praxis und kennt daher auch die praktischen Probleme und Grenzen bei Nutzung und Einführung von Objectives & Key Results (OKR). Zunächst definiert sie, was OKR überhaupt sind und wie sie funktionieren. Wir diskutieren, in welchen Situationen OKR besonders effektiv eingesetzt werden können und welche Vorteile sie im Vergleich zu anderen Zielsetzungsmethoden bieten. Gleichzeitig beleuchten wir auch die Grenzen von OKR und wann sie möglicherweise nicht die beste Wahl sind. Ein wichtiger Aspekt ist die Einführung von OKR in Unternehmen. Hier teilt Christina Lange ihre Erfahrungen und Tipps, um einen erfolgreichen Start mit OKR zu gewährleisten, inkl. der Strategien zur Bewältigung von Problemen mit bzw. den "Missbrauch" von OKR. Besonders interessant ist für unseren Podcast natürlich die Rolle von Product Ownern im OKR Kontext. Tim bespricht mit Christina, wie Product Owner OKR nutzen können, um ihre Produktstrategie zu unterstützen, und welche Herausforderungen sich dabei ergeben können. Des Weiteren wird beleuchtet, wie OKR mit Scrum zusammenpassen und wie sie sich grundsätzlich in agile Arbeitsweisen integrieren lassen. Abschließend betrachten wir die Anwendung von OKR im Kontext von Product Discovery und wie sie die Produktentwicklung und Innovationsprozesse unterstützen können. Erwähnte Podcast-Episoden: - Product Coaching - Gast: Annette Greil - Was die Einführung von OKR für Product Owner bedeutet - Gast: Stefanie Götten Erwähnte und empfohlene Bücher & Quellen: - Christina Lange: OKR in der Praxis: Objectives & Key Results – Beispiele, Hacks, Erfahrungen - Ben Lamorti: The OKRs Field Book: A Step-by-Step Guide for Objectives and Key Results Coaches - John Doerr: Measure What Matters - How Google, Bono, and the Gates Foundation Rock the World with OKRs - Christina Wodtke: Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results - Bart Den Haak: Moving the Needle With Lean OKRs: Setting Objectives and Key Results to Reach Your Most Ambitious Goal - Blog von Filipe Castro: OutcomeEdge.com Falls du weitere Fragen hast und gerne Kontakt zu Christina Lange aufnehmen möchtest, dann verbinde dich mit ihr über ihr LinkedIn-Profil. Sie freut sich über deine Nachricht. Weiterhin möchten wir euch den Blog von Christina Lange ans Herz legen: pragmaticchange.com Welche Erfahrungen habt ihr mit der Einführung von Objectives & Key Results gemacht? Wie fühlen sind OKR in der Praxis bei euch an und wie arbeitest du als Product Owner mit den OKR? Kannst du sie in deine Arbeit einbinden? 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. **Folgt uns Produktwerkern auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Eine der häufig gestellten Fragen ist, wer eigentlich festlegt, wer zum Product Owner ernannt wird. Da uns diese Frage oft gestellt wird, diskutieren Tim und Dominique in dieser Folge über ihre Erfahrungen. Zunächst werfen wir einen Blick in den Scrum Guide, müssen jedoch feststellen, dass dort nicht viel dazu steht. Trotzdem haben sich in der Praxis verschiedene Möglichkeiten entwickelt, wie Organisationen die Rolle des Product Owners vergeben. Eine Möglichkeit ist beispielsweise, jemanden direkt aus dem Team zu ernennen. Alternativ wird diese Entscheidung oft durch das Management oder die Stakeholder getroffen. Hierbei gibt es verschiedene Ansätze, insbesondere in Bezug darauf, wie stark das Team in den Auswahlprozess einbezogen wird. In Bezug auf die Rolle des Scrum Masters stellt sich dann die Frage, wie diese Person bei der Suche nach der besten Besetzung für die Position des Product Owners unterstützen kann. Dann gehen Tim und Dominique ins Detail und besprechen die Auswahlprozesse, die sie bereits erlebt haben. Diese reichen von umfassenden und simultanen Einführungen, über einen Rekrutierungsprozess mit kollegialer Unterstützung, bis hin zu einem internen Assessment. Manchmal wird die Auswahl auch durch externen Druck beeinflusst, wenn beispielsweise ein Fachbereich gezwungen wird, einen Product Owner zu stellen. Dies kann dazu führen, dass man als Product Owner plötzlich ein zweites Produkt mit einem zweiten Produktteam betreuen muss. Obwohl dies nicht ideal ist, bietet es zumindest die Möglichkeit, dass das Produktteam mehr Verantwortung übernehmen kann. Erwähnte Podcastfolgen - Und plötzlich war ich dann Product Owner - Ein Erfahrungsbericht (https://produktwerker.de/und-ploetzlich-war-ich-dann-product-owner-ein-erfahrungsbericht/) - Seine Stakeholder kennen und richtig analysieren (https://produktwerker.de/stakeholder-analysieren/) - POEM - Product Ownership Evolution Model (https://produktwerker.de/poem-product-ownership-evolution-model/) Wie bist du in die Product Owner Rolle gekommen? Wer legt bei euch fest, wer Product Owner wird oder wann man es auch nicht mehr ist? Wie läuft das bei euch? Lass uns gerne einen Kommentar auf unserer Webseite (www.produktwerker.de) oder auf LinkedIn (https://www.linkedin.com/company/produktwerker) da.

Yoga für Product Owner: Nadja Deuerlein ist Product Ownerin und Yoga-Lehrerin. Während ihrer persönlichen Lernreise von einer Softwareentwicklerin zur PO als auch zu einer ausgebildeten Yoga-Lehrerin hat sie interessante Parallelen zwischen agiler Produktentwicklung und Yoga beobachtet. Und genau über diese Erkenntnisse spricht Nadja in dieser Episode mit Oliver. Zu Beginn der Folge erklärt Nadja, dass Yoga mehr ist als die bekannten Asanas - die Körperstellungen bzw. Körperlichen Übungen - und Dyhana - die Meditation. Im Yoga-Sutra werden unter anderem auch die Yamas und die Niyamas beschrieben. Bei den Yamas handelt es ich um einen Verhaltenskodex gegenüber der eigenen Umwelt. Die Niyamas umfassen dagegen das Verhalten zu sich selbst. Vereinfacht gesagt werden hier Normen und Regeln zusammengefasst, die für das zwischenmenschliche Handeln Relevanz haben. Oliver diskutiert mit Nadja, welche Schnittmenge es zwischen diesen „10 Geboten“ des Yogas und den Herausforderungen als Produkt Owner gibt. Nadja erklärt alle 5 Yamas und 5 Niyamas und überträgt diese auf ihre Aufgaben als Product Ownerin. Ihr Erfahrenbericht gibt eine ganze Reihe wertvoller Tipps und Trick für die Weiterentwicklung der eigenen Persönlichkeit. Die beiden ziehen darüber hinaus Vergleiche zum Agilen Manifest und dessen Ziel. Wie immer endet die Episode mit praktischen Tipps und Tricks für deine eigene Product Owner Tätigkeit.

Die Herausforderung als Product Owner lässt einen oft unter dem Druck stehen, alles gleichzeitig zu managen. Wir stellen die brennende Frage: Was mache ich, wenn ich als Product Owner keine Zeit für alles, was ich tun möchte, muss oder sollte, habe? Das Empfinden, keine Zeit zu haben, entsteht oft erst einmal dadurch, dass viel Arbeit liegen bleibt oder man zumindest das Gefühl hat, sich nicht mit den wichtigen Dingen beschäftigen zu können. Man ist getrieben und fühlt sich oft fremdgesteuert. Das Erste, was man dann machen sollte, ist, die eigene Zeit und vor allem den Einsatz der eigenen Zeit zu erheben. Durch das Mittracken der eigenen Zeit und das kritische Analysieren der Ergebnisse (Inspect & Adapt) bieten sich Einblicke, wie man effektiver arbeiten kann. Die wichtigste Methode dabei ist, mehr Fokus herzustellen. Wir diskutieren bewährte Methoden, um den Arbeitsalltag besser zu strukturieren. Von der Anlage eines Backlogs für eigene Aufgaben über die Pomodoro-Technik bis hin zum Einsatz eines Bullet Journals – diese Techniken helfen dabei, den Fokus zu schärfen und produktiver zu sein. Oft ist der Fokus aber gar nicht so schnell herstellbar. Daher haben wir Tipps besprochen, wie man sofort mehr Zeit gewinnen kann. Wir erörtern, wie das Ausschalten von E-Mail-Benachrichtigungen, das Verkürzen von Meetings, das Einfordern von Meeting-Agendas und der Grundsatz „Nach drei E-Mails lieber anrufen“ den Arbeitstag effizienter gestalten können. Zudem betonen wir die Wichtigkeit, feste Fokuszeiten im Kalender zu planen und diese auch einzuhalten. Für die langfristige Perspektive besprechen wir Strategien wie das Setzen von regelmäßigen Terminblockern im eigenen Kalender, das Delegieren von Aufgaben und den Aufbau einer Stakeholder-Community. Diese Ansätze unterstützen nicht nur eine bessere Zeiteinteilung, sondern auch eine effiziente und effektive Zusammenarbeit. Abschließend teilen wir einige Ratschläge, darunter die Kraft des Bullet Journals, um sich jeden Morgen auf die wichtigste Aufgabe zu konzentrieren, bevor digitale Geräte eingeschaltet werden. Außerdem betonen wir die Bedeutung eines nachhaltigen Arbeitstempos (sustainable pace), das langfristigen Erfolg sichert und das Einplanen von Pausen beinhaltet. Am Ende muss man schon fast sagen, dass keine Zeit zu haben eine Lüge ist. Ehrlicherweise heißt es nämlich oft, dass andere Sachen wichtiger sind. Wir würden uns aber freuen, wenn ihr uns schreibt, wie ihr damit umgeht keine Zeit zu haben. Was sind eure Techniken, Strategien und Tipps, die ihr mit andern Teilen könnt? Gerne hier als Kommentar oder auf LinkedIn.

Als Product Owner und Produktmanager führe ich in unterschiedlicher Art und Weise. Daher blickt Oliver in dieser Podcastfolge gemeinsam mit Simonetta Batteiger erneut auf das Thema Leadership Skills. Simonetta arbeitet als Beraterin, Trainerin und zertifizierte Coachin für Produktführungskräfte und Executives und legt dabei auch einen Fokus auf Inclusive Leadership. Denn ihrer Meinung nach ist erfolgreiche Produktarbeit Führungsarbeit. Zu Beginn des Gespräches teilt Simonetta ihre Sicht, warum Leadership für mich als Product Owner so wichtig ist. Deshalb gilt es natürlich auch zu klären, was Leadership überhaupt ist und wie das mit der Verantwortlichkeit als Produktmensch zusammenpasst. Simonetta hat in einem Talk auf den PO Days bereits drei essentielle Skills geteilt. In der Podcastfolge mit Oliver gehen die beiden auf die einzelnen Aspekte noch einmal detaillierter ein. Erstens ist es elementar, dass die Richtung in die unser Produkt entwickelt werden soll, klar ist und von allen Beteiligten verstanden wird. Als Produktmanager obliegt mir vor allem dafür zu sorgen, dass eine Vision, eine Strategie und eine Product Roadmap existiert und diese kommuniziert werden. Zweitens kann jede Führungskraft Coaching Habbits entwickeln, die in der Zusammenarbeit mit anderen Menschen helfen können. Und drittens gestalte ich das Team, mit dem ich das Produkt entwickle, auch immer bis zu einem gewissen Punkt mit. Denn in unserer Verantwortlichkeit werden wir niemals alleine agieren und alleine erfolgreich sein können

Für diese Folge haben wir uns in der Vorbereitung richtig Zeit genommen. Wir wollten ursprünglich über alle typischen Fallen sprechen, in die Product Owner immer wieder tappen. Herausgekommen ist eine Sammlung von 10 Fallen, die Product Owner immer wieder machen. Eine Top 10? Vielleicht. Aber in erster Linie die 10 Fehler, die unserer Meinung nach am dringensten vermieden werden sollten. Die Reihenfolge ist natürlich keine Priorisierung. Je nach Kontext sind andere Fallen kritischer, wichtig oder häufiger. Aber genug der Einleitung. Hier unsere 10 Fehler, in die Product Owner immer wieder tappen: - Nicht auf sich selbst achten - Zum Projektleiter werden - Übernahme von Scrum Master Tätigkeiten - Selbstorganisation des Teams stören - Keine Klarheit über die Rolle haben - Schlechte Stakeholder-Kommunikation - Kundenbedürfnisse zu wenig wahrnehmen - Keine Insights sammeln - Die Produktvision aus den Augen verlieren - In Lösungen statt in Opportunities denken Wir glauben daran, dass diese 10 Fallen immer wieder auftreten und das wir uns als Product Owner dessen bewusst sein müssen. Für einige werden es andere Fallen sein aber am Ende geht es doch darum ein erfolgreiches Produkt zu entwickeln und sich dabei auch wohl zu fühlen. Wir sollten den Wert unserer Arbeit für uns, unser Team, unser Produkt und unserer Organisation steigern. Die Auswahl ist natürlich sehr subjektiv. Das ist uns vollkommen klar. Wir glauben aber dennoch vielleicht den ein oder anderen Impuls bieten zu können. Und wer weiß, vielleicht machen wir bald zu jeder dieser Fallen eine eigene Folge. Vorher aber die Frage an euch, welche Falle euch immer und immer wieder begegnen, entweder weil ihr selbst hineingeratet oder andere dabei beobachtet. Lass gerne einen Kommentar mit euren Erfahrungen hier oder auf dem Post bei LinkedIn.

Wir haben einen Website-Relaunch vollzogen und dabei versucht, agil und inkrementell vorzugehen. Das ist aber gar nicht so einfach, weil das auch nicht jede Agentur mitmacht, die man ggf. dafür braucht. Einiges an dieser Produktentwicklung hat gut geklappt - bei anderen Sachen haben wir selbst mal wieder eine Menge gelernt. Wir berichten, welche User Probleme und Business Needs uns initial dazu gebracht haben, unser "Produkt" Website nochmal grundlegend zu überarbeiten und wie wir diese Aufgabe angegangen sind. Natürlich berichten wir auch darüber was gut geklappt hat und über unsere Fehler. Natürlich kämpfen auch wir selbst mit der Frage, wann es "gut genug" ist bzw. wann das Ergebnis unserem Anspruch genügt um live zu gehen. Tim und Oli berichten zudem, wie sie die Zusammenarbeit mit der Agentur agil gestalten konnten und welche Erfolgsmetriken sich die Produktwerker selber für den Website-Relaunch gesetzt haben. Ein großes Problem welches wir mit dem Website-Relaunch lösen wollen, ist die bessere Auffindbarkeit von unseren ganzen älteren Podcast-Folgen. Da steckt noch soviel wertvoller Content drin, aber bei nun schon 211 Episoden fand man diese "Perlen" gar nicht mehr so einfach. In den üblichen Podcast-Playern ist das eh nahezu unmöglich, aber auf unserer Website gab es halt auch nur eine unsäglich lange Liste. Also haben wir nun eine Schlagwortsuche und vor allem eine Filterung nach thematischen Kategorien eingebaut. Insbesondere zu dieser neuen Podcast-Suche wollen wir euch nun ganz herzlich um euer Feedback bitten und geben euch im Gegenzug die Chance einen tollen Preis zu gewinnen. Geht einfach auf der Website auf die Seite Podcast und klickt auf den Feedback-Button. Unser allen Einsendungen von Feedback verlosen wir einen Platz in unserem Strategietraining am 23./24.April in Köln. Zu dieser Episode passen diese älteren Folgen: - Als Product Owner auf Seiten einer Agentur - Zusammenarbeit mit einem UX-Dienstleister - Der Product Owner aus Sicht eines Dienstleisters Wir möchten uns an dieser Stelle ausdrücklich bei unserem geschätzten Kooperationspartner Webrunners und Geschäftsführer Adrien Simon bedanken. Insbesondere gilt aber unser Dank Finja Kolzem, die für und mit uns verantwortlich die neue Seite gebaut hat. Danke für Deinen großartigen Einsatz liebe Finja! Ebenfalls geht ein großes Dankeschön an Marek Nowacki (snckbl media) für unser überarbeitetes Corporate Design. Welche Erfahrungen habt ihr evtl. schon mal bei der Erstellung einer neuen Website gemacht? Inwiefern war das für euch inkrementell machtbar und hattet ihr dafür einen passenden Dienstleister bzw. Agentur, die dabei mitgespielt hat? 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. **Folgt uns Produktwerkern auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Ist der Product Owner eine laterale Führungskraft? Hat man in der Verantwortung als Product Owner auch Führungsverantwortung? Und wenn ja, wie stellt sie sich dar? Tim und Dominique klären in dieser Episode zunächst mal die Frage, was denn unter lateraler Führung zu verstehen ist und ob man als Product Owner grundsätzlich eine Führungsrolle inne hat. Dies leben Unternehmen tatsächlich auch sehr unterschiedlich und oft hängt es auch davon ab, welches Ansehen und Rollenverständnis im Rahmen der Produktentwicklung der Product Owner Verantwortlichkeit zugestanden wird. Es kommt also sehr oft auf das Hierarchieverständnis innerhalb der Organisation an, ob ein Product Owner als laterale Führungskraft im Unternehmen wirken kann. Die Herausforderung ist dann, ohne formale Macht eine (inhaltliche) Führung zu übernehmen. Führung bezieht sich für Product Owner dann vor allem für das Produkt und die Führung im Sinne der zielgerichteten Ausrichtung des Scrum Teams auf Produktvision und Produktziele. Eine entscheidende Frage ist aber auch, wie sich die Stakeholder gegenüber der Product Owner Rolle verhalten bzw. ob sie einen Product Owner als laterale Führungskraft akzeptieren. Ferner diskutieren die beiden Produktwerker aber auch, wo laterale Führung ggf. nicht hilft oder vielleicht sogar schädlich ist. Mit einer zusammenfassenden Betrachtung der Vorteile von lateraler Führung als Product Owner schließt die Folge ab. Das Thema war übrigens ein Hörerwunsch. Wir freuen uns immer wieder, wenn ihr uns Themenvorschläge macht. Im Gespräch wird auf diese Folgen verwiesen: Das Product Operating Model von Marty Cagan Introvertiert als Product Owner - geht das? Stakeholder Community Product Principles Und diese Literaturempfehlungen gab es: Patrick Lencioni: The Five Dysfunctions of a Team Geoff Watts: Product Mastery Wie ist eure Meinung? Kann die Product Owner die Verantwortlichkeit so leben, dass er bzw. sie als laterale Führungskraft zu wirken? Sind bei euch im Unternehmen Product Owner Führungskräfte bzw. werden als solche betrachtet? 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. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Diesmal hatten wir das Vergnügen, Annette Greil (https://www.linkedin.com/in/annette-greil-7a6333107/) zu begrüßen, die ihr Rollenverständnis und ihre Erfahrungen als Product Coach bei der METRO.digital mit uns teilte. Product Coaching befähigt die Organisation über traditionelle Produktentwicklung hinauszugehen, um letztendlich herausragende Produkte zu entwickeln. Eine typische Woche im Leben eines Product Coaches, so Annette, gibt es eigentlich nicht. Sie verbringt ihre Zeit mit einer Vielzahl von Aufgaben, von Einzelgesprächen mit Teammitgliedern über die Moderation von Workshops bis hin zur Analyse von Produktstrategien und der Optimierung von Arbeitsabläufen. Product Coaches arbeiten intensiv mit Product Ownern, Product Managern und Product Leadern zusammen. Die erforderlichen Kompetenzen für diese Rolle sind ebenso vielfältig, einschließlich starker Kommunikationsfähigkeiten, Empathie, einem tiefen Verständnis für Produktmanagement-Praktiken und einer ausgeprägten Fähigkeit, komplexe Probleme zu lösen. Die digitale Landschaft ändert sich rasant, und als Coach muss man sich kontinuierlich weiterbilden, um auf dem neuesten Stand der besten Praktiken und Technologien zu bleiben. Annette schließt nicht nur mit einigen wertvollen Tipps für angehende Product Coaches ab, sondern wagt auch einen Blick in die Zukunft. Wie wird sich das Product Coaching in den kommenden Jahren verändern? In der Folge haben wir kurz auch auf unsere OKR Folge referenziert. Hört dort auch gerne rein, um mehr über OKR und ihre Rolle für Product Owner zu erfahren -> https://produktwerker.de/okr-product-owner/

Dominique und Oliver greifen in dieser Episode eine Frage auf, die uns vor einiger Zeit ein Zuhörer mit einem Augenzwinkern gestellt hat: “Wann lohnen sich Product Owner?” Und vor allem, wann lohnt es sich nicht, diese Verantwortlichkeit in Unternehmen zu etablieren. Aus der Diskussion ergibt sich eine gute Zusammenfassung, was aus ihrer Sicht einen Product Owner ausmacht bzw. bei welchen Rahmenbedingungen man von einem Product Owner sprechen kann. Sofern ich die im Scrum Guide formulierte Vorstellung eines POs ernst nehme, gewinnen Teams durch eine bevollmächtigte Product Owner vor allem drei Dinge: klare Verantwortlichkeit bei Produktentscheidungen, Entscheidungsgeschwindigkeit und Fokus auf die Kunden- und Unternehmenbedürfnisse. Wichtig ist hierbei, dass POs auch Produktmanager sein dürfen und können. Förderung von Agilität Als besonders wichtig stellen Dominique und Oliver heraus, dass auch ein Product Owner ein besseres Verständnis für Hypothesen getriebenes Arbeiten und Produktentscheidungen unter Unwissenheit in seinem eigenen Umfeld entwickeln kann. Auch hier kann die Einführung der Rolle lohnenswert sein. Die beiden Gesprächspartner diskutieren natürlich auch die Kehrseite der Medaille, nämlich wann Product Owner auch nicht wirklich weiterhelfen. Und wie immer schließen sie die Podcastfolge mit praktischen Tipps & Tricks aus dem eigenen persönlichen Erfahrungsschatz ab.

In dieser Folge haben wir Marcel Mellor, Product Lead von sipgate, zum Thema "Innovation im Unternehmen" zu Gast. Marcel ist Produktstratege und spannender Weise auch Science Fiction Autor, was ja per se schon nah an innovativen Themen ist. Tim diskutiert im Rahmen eines Erfahrungsberichts zum Innovationsprodukt "satellite" mit Marcel, wie Innovation im Unternehmen gelingen kann und ob und wie eine Innovation z.B. in einem sprint-basiertem Ansatz wie Scrum gut gelingen kann. Natürlich steht zu Beginn die Frage, was Innovation für Marcel bedeutet und wie er ganz persönlich zu dem Interesse an Innovationsarbeit gekommen ist? Besonders spannend sind die Learnings, die Marcel Mellor im Zuge der Innovationsreise mit dem Produkt satellite selbst für sich über Innovation gelernt hat. Die beiden diskutieren, welche Erfolgsfaktoren und Hindernisse sie für Innovation im Unternehmen sehen. Ein Bezug zu Innovation und KI darf dabei natürlich auch nicht fehlen. In Summe ist ein sehr inspirierender Erfahrungsaustausch mit einem echten Innovationsprofi entstanden. Empfohlene Quelle zum Thema Innovation im Unternehmen: - Steven Johnson:- Aufzählungs-Text Wo gute Ideen herkommen: Eine kurze Geschichte der Innovation Diese alten Episoden wurden im Gespräch erwähnt: - Mit Storytelling andere von Deinen Produktideen überzeugen - Warum scheint die Product Owner Rolle so schwer zu sein? (mit Markus Andrezak) - Business- oder Nutzersicht: Welchen Blickwinkel sollte ein PO einnehmen? (mit Markus Andrezak und Sohrab Salimi) Wenn ihr mehr Content von Marcel Mellor hören bzw. lesen wollt, folgt ihm auf LinkedIn oder hört einen seiner beiden Podcasts: - Podcast: "Skalierbar" (mit David Ranftler) - Podcast: Tech is Good - Das aktuelle Buch von Marcel Mellor: Das Register - Personal Website: marcelmellor.com Und falls ihr euch für das Product "satellite" näher interessiert, gibt's hier alle Infos: https://satellite.me/ Wird echt Innovation im Unternehmen aus Deiner Sicht durch agile Frameworks wie z.B. behindert oder gefördert? Oder hälst Du die Wahl des Ansatzes für unerheblich für den Erfolg der Innovation? 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. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Das Product Backlog ist die eine einzige Stelle, an der wir Arbeit organisieren, die für unser Produkt getan werden soll. Klassischerweise ist das Product Backlog eine priorisierte Liste. Aber muss es das sein? Wichtig ist doch vor allem die Priorisierung, oder? In dieser Folge unterhalten sich Oliver und Dominique über weitere Alternativen, wenn es um eine gute Organisation des Product Backlogs geht. Alternativen lassen sich schnell finden. Einige Methoden sind recht bekannt, wie beispielsweise die User Story Map. Hier bewegen wir uns entlang der User Journey und organisieren das Product Backlog in zwei Dimensionen. Aber auch andere Methoden wie Classes of Work können hilfreiche Übersicht geben. Hierbei wird die Arbeit in verschiedene Arten aufgeteilt und seperat voneinander priorisiert. Und dann gibt es noch Alternativen aus anderen Bereichen wie beispielsweise ein Funnel Backlog, bei dem wir uns mehr darauf konzentrieren, welche Arbeiten in welchen Funnelbereichen gerade notwendig sind. Und dann sind da noch Impact Maps, Vorgangsknotennetzpläne und einige mehr. Am Ende haben die alternativen Organisationsformen alle ihre Vor- und Nachteile. in unserer Arbeit als Product Owner, Product Manager und Product Leader müssen wir daher abwägen, welche Art sich gerade mehr als andere anbietet. Mal kann das Aufzeigen von Abhängigkeiten wichtiger sein, mal die absolute Serrialisierung von Arbeit. Oft hängt es am Ende auch an der Zusammenarbeit mit der eigenen Stakeholdercommunity.

Die Gründung eines eigenen Unternehmens ist eine faszinierende und reizvolle Angelegenheit, besonders für Personen, die in der Produktentwicklung tätig sind. Diese Tätigkeit ermöglicht es, eigene Produkte intensiver zu formen und persönliche Ideen Wirklichkeit werden zu lassen. Ein interessanter Ansatz hierbei ist das Ausgründen aus einem Konzern. Für Positionen wie Product Owner, Product Manager oder Product Lead kann dies eine attraktive Option sein. In diesem Zusammenhang haben wir uns mit Christian Fahl unterhalten, der das Unternehmen Loql als Ausgründung aus der REWE Group mit ins Leben gerufen hat. Christian ist heue Product Lead bei Loql und teilt seine Erfahrungen über den Gründungsprozess und wie alles für ihn begann. Besonders aufschlussreich sind die Schritte, die er noch vor der eigentlichen Ausgründung unternommen hat. Diese Phase ist nicht ohne Herausforderungen, auf die Christian ebenfalls eingeht. Seine persönliche Perspektive und Erfahrungen bieten hierbei spannende Einblicke. Ein weiterer wichtiger Aspekt der Ausgründung ist die Zusammenarbeit zwischen dem neu gegründeten Unternehmen und dem Mutterkonzern. Auch hierzu liefert Christian interessante Informationen. Zum Abschluss gibt er noch einige Ratschläge, die ihm im Rückblick geholfen haben, den Prozess der Unternehmensgründung zu erleichtern.

Gegen Ende eines jeden Jahres kommen die Thema Budget- und Roadmapplanung wieder auf die Tagesordnung. Und in die Planung dieser jährliche Roadmap werden wir als Product Owner*in dann intensiv eingebunden. Aber lohnt der Aufwand, den wir in diese Themen investieren? Tim und Oliver diskutieren diese Fragen vor allem auf Basis ihrer eigenen Erfahrungen. Nachdem die beiden reflektiert haben, warum eine jährliche Planung für viele Unternehmen immer noch wichtig ist, geben sie einen kurzen Überblick über die Unterschiede zwischen Projekt- und Produkt-Roadmaps. Da aber die Mehrzahl unserer Ideen für die Produktentwicklung nicht funktionieren oder zumindest mehrere Iteration brauchen, bis sie die Business-Ziele generieren können die wir uns erhofft haben, stellt sich die Frage, ob eine jährliche Roadmapplanung auch wegen der Kompexität und Unsicherheiten im eigenen Produktkontext überhaupt sinnvoll ist. Tim und Oliver bieten in dieser Folge einige Lösungsansätze, wie man besser mit Roadmaps umgehen und arbeiten kann. Wir immer teilen die beiden zum Abschluss der Episode Tipps und Tricks.

Der Berufsstand der UX-Professionals hat in den letzten Jahren eine Differenzierung erlebt, und es sind neue Teildisziplinen entstanden. Eine dieser Disziplinen ist das UX-Management, und mittlerweile gibt es einige Menschen, die die Verantwortung als UX-Manager in Projekten und Organisationen übernehmen. Durch ihre Arbeit prägen sie die Produktentwicklung; es lohnt sich also zu fragen, was das genau ist und wie diese Disziplin Menschen in Verantwortungspositionen als Product Owner, Product Manager oder Product Lead bei der Entwicklung großartiger Produkte unterstützt. Dazu haben wir den UX-Experten Andreas Hinderks eingeladen, der nicht nur beruflich viel mit dem Thema zu tun hat, sondern auch intensiv dazu forscht. Wir klären also zunächst, was UX-Management ist, was manche vielleicht darunter verstehen und wie sich diese Tätigkeit in den Kontext der Produktentwicklung einfügt. Dabei wird schnell deutlich, dass Management nicht ohne Strategie, Ziele und Ressourcen gedacht werden kann. Für Produkte sollten also idealerweise Ziele für eine gute UX gesetzt, eine Strategie zur Zielerreichung festgelegt und die angemessenen Ressourcen zugeteilt werden. Dass dies am besten im Team funktioniert, versteht sich fast von selbst, denn es geht um die Schaffung von Erlebnissen für Menschen. Natürlich tauschen wir uns mit Andreas auch über gute und schlechte Praktiken aus, damit nicht dieselben Fehler wiederholt werden müssen. Nach einigen Prognosen zur Zukunft des UX-Managements gibt Andreas zum Schluss noch einige weitere hilfreiche Tipps zum Thema UX-Management für Product Owner.

Velocity ist in der agilen Softwareentwicklung, vor allem in Scrum, weit verbreitete Metrik, die die Arbeitsmenge eines Teams in einem Sprint misst. Aber ihre Nutzung birgt auch bestimmte Grenzen, die Tim und Dominique in dieser Folge kritisch hinterfragen. Velocity, meist in Story Points gemessen, gibt an, wie viel ein Team in einem (durchschnittlich) Sprint leistet. Sie ist hilfreich für die Sprint-Planung und kann die Vorhersagbarkeit verbessern. Doch als reine Output-Metrik vernachlässigt sie wichtige Aspekte wie Outcome und die Qualität der Arbeit. Ein kritischer Punkt, den Tim und Dominique betonen, ist, dass Velocity eine relative Größe ist, die nur innerhalb eines Teams Bedeutung hat. Der Vergleich von Velocity zwischen verschiedenen Teams ist problematisch und kann vorsichtig gesagt mindestens zu Missverständnissen führen. In der Diskussion heben die beiden hervor, dass Teams Velocity als Werkzeug zur Reflexion nutzen sollten, nicht als starres Ziel. Es geht darum, den tatsächlichen Wert und die Qualität der Arbeit zu verbessern - nicht um die reine Liefergeschwindigkeit als Selbstzweck. Andere Metriken, die Kundenzufriedenheit und Outcome zu messen, erscheinen sogar wichtiger zu sein. Interessanter Weise wurde die Velocity früher in Scrum Trainings viel stärker betont, Zusammen mit dem allgemeinen Trend, mehr Wert auf Outcome bzw. Wirkung zu legen, statt eine reine Product Delivery zu fokussieren, wird auch in den Trainings immer seltener über Velocity gesprochen. Neben den Problemen und Fehlern im Umgang mit Velocity betrachten Dominique und Tim natürlich auch die Vorteile des Einsatzes dieser Metrik. Weiterhin geben sie Tipps zum richtigen Einsatz von Velocity. In dieser Folge wird auf diese Episoden im Gespräch verwiesen: - Wann ist das fertig? Keine Ahnung, wir sind ja agil! - Forecasting in der agilen Produktentwicklung - Evidence Based Management - eine empirische Suche nach Wert Nutzt ihr bei euch Velocity als Metrik? Wenn ja, wie gelingt es euch, dass diese Metrik auch positiv im Hinblick auf den Wert des entwickelten Produkts wirkt und nicht zu einem Team-Kontrollinstrument verkommt? 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. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Zu Beginn des Jahres bietet es sich an einmal Gedanken zu den eigenen, ganz persönlichen Zielen im neuen Jahr zu machen. In dieser Folge teilt Dominique eigene Erfahrungen und Tipps rund um das Setzen effektiver, persönlicher Ziele – sowohl für das Produkt als auch für die persönliche Entwicklung. Das Setzens von Zielen ist entscheidend, um einen klaren Fokus zu erzeugen. Ein zentrales Thema ist schon ein echter Klassiker: smarte Ziele. Diese Methode hilft dabei, Ziele zu definieren, die spezifisch, messbar, erreichbar, relevant und zeitgebunden sind. Ein besonderer Fokus liegt darauf, wie diese Prinzipien auf die einzigartigen Herausforderungen von Product Ownern und Product Leadern angewandt werden können. Persönliche Ziele, die greifbar und messbar werden, können in der Regel besser erreicht werden. Gerade Produktverantwortlichen müsste es besonders leicht fallen diese Ziele anschließend auch zu bewerten und in eine Reihenfolge zu bringen. Für die persönliche Entwicklung bedeuten klare Ziele: Von der Steigerung spezifischer Kompetenzen bis hin zur Bedeutung von Work-Life-Balance mit den richtigen Maßnahmen die richtigen Schritte gehen. Vielzuoft entscheiden sich Menschen für kurzfristige Belohnungen und vbergessen dabei, dass längerfristige Ziel im Blick zu behalten. Dazu wurden in dieser Folge einige praxisnahe Tipps und Methoden geteilt. Vorgestellt wurden verschiedene Tools und Apps zur Zielverfolgung sowie Zeitmanagement-Strategien, die speziell für die Bedürfnisse von Product Ownern und Product Leadern zugeschnitten sind.

In dieser besonderen Zeit des Jahres, wo wir einen Moment innehalten und das Vergangene reflektieren, möchte ich meine Gedanken und Erfahrungen zum Thema Reflexion mit euch teilen. Diese Zeilen begleiten unsere Podcastfolge, in der Dominique ausführlich über Reflexion spricht, ein Thema, das unserer Meinung nach für Product Owner, Product Manager und Product Leads gleichermaßen relevant ist. Reflexion ist ein wesentlicher Bestandteil des agilen Produktmanagements, bekannt durch Praktiken wie die Retrospektive. Es geht um mehr als nur das Zusammenfassen vergangener Ereignisse; es ist eine Gelegenheit, aus Erfahrungen zu lernen und sich persönlich sowie beruflich weiterzuentwickeln. Für uns ist es wichtig, regelmäßig innezuhalten und sowohl berufliche als auch private Erlebnisse zu reflektieren. Dominiques Reflexionstechniken, die er gerne empfiehlt: Das weiße Blatt: Hierbei man sich stumpf mit einem leeren Blatt Papier hin und notiert alles, was einem zum vergangenen Jahr einfällt. Dies kann zu einer Mindmap oder Sketch Note werden und hilft, die eigenen Gedanken zu ordnen und neue Perspektiven zu gewinnen. Klingt irgendwie zu simpel aber hilft. Reflektionsgespräche: Diese Gespräche führt man mit vertrauten Personen, um Feedback zu bekommen und die eigenen Gedanken weiterzuentwickeln. Es geht hierbei nicht nur um Kritik, sondern um das Erkennen neuer Möglichkeiten und das Ausloten unterschiedlicher Perspektiven. In der Regel reichen zwei bis drei Gespräche. Die persönliche Retrospektive: Nicht nur am Jahresende sondern einmal im Monat kann man sich die Zeit nehmen für eine tiefgehende Reflexion der eigenen Aktivitäten und Entscheidungen. Dies beinhaltet das Durchgehen des eigenen Kalenders und Trello-Boards, um zu verstehen, was man erreicht hat und was noch aussteht. Reflektieren allein genügt nicht. Es geht darum, Konsequenzen aus den eigenen Erkenntnissen zu ziehen. Das bedeutet, Entscheidungen zu treffen, Ziele zu setzen und konkrete Maßnahmen zu ergreifen, um das Beste aus der eigenen Zeit und den eigenen Fähigkeiten herauszuholen. Und nach einer intensiven Reflexionsphase ist es wichtig, sich auch zu belohnen. Das kann eine Aussicht auf neue Ziele sein, eine kleine Freude wie ein leckeres Essen oder einfach die Zufriedenheit, sich selbst Zeit und Raum für persönliches Wachstum gegeben zu haben. Wir hoffen, dass diese Einblicke euch als Impulse dienen und euch gleichzeitig ermutigen die notwendige Zeit für Reflexion zu nehmen. Nutzt die ruhige Zeit zwischen den Jahren, um über das vergangene Jahr nachzudenken und Pläne für die Zukunft zu schmieden. In diesem Sinne wünschen wir euch besinnliche Feiertage und einen guten Start ins neue Jahr!

Was ist ein Produkt? Und ist eine Dienstleistung ein Produkt? Beides sind oft gehörte Fragen. Dominique und Tim greifen diese Fragen auf und diskutieren in dieser Episode rund um den Produktbegriff. Zunächst gucken sie sich gängige Definitionen an. Ein übliches Produktverständnis umfasst auch Services bzw. Dienstleistungen. Oft fällt es Organisationen aber noch schwer, die Frage zu klären "Was ist ein Produkt" und wie schneiden wir dementsprechend die jeweiligen Teams rund um die Produkte. Aber was ist, wenn ich als Product Owner nach diesen Definitionen gar kein "Produkt" habe? Vielleicht verantwortet man also eine Komponente, ein Feature oder eine Plattform. Kann man dann dennoch produkthaft vorgehen? Und was ist mit internen Produkten? Sind das eher Anwendungen oder kann man sie auch als Produkt bezeichnen? In diesem Zusammenhang diskutieren die beiden auch kurz, ob und wann eine API ein Produkt ist und wann nicht. Am Rande sprechen die beiden auch nochmal über die Abgrenzung von Nutzer und Kunde. Auch hier werden in der Praxis die Begriffe oft etwas zu nachlässig verwandt. Empfohlene Quellen zur Frage "Was ist ein Produkt": - Marty Cagan (svpg): What is a Product? - Definition "Was ist ein Produkt" aus dem Scrum Guide - Roman Pichler "Six Types of a "Product" Owner" In dieser Episode empfohlene Podcast Folgen: - Vom Projektleiter oder Teamleiter zum Product Owner - Scrum Product Owner vs. SAFe Product Owner - ein Missverständnis - Wardley Mapping - Produktstrategie wie ein Schachspiel - POEM - Product Ownership Evolution Model - Evidence Based Management - eine empirische Suche nach Wert Kennst du diese Fragestellung "Was ist Produkt"? Wird die Diskussion bei euch auch im Rahmen des Produktschnitts geführt? Wie definiert ihr eure Produkte? Und wie geht ihr mit Dienstleistungen bzw. Services um? 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. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

"Wir werden das Produkt einstellen - es ist zwar noch erfolgreich, passt aber nicht mehr zur künftigen Unternehmensstrategie." Wenn man solch eine Entscheidung hört, ist klar, dass das Ende des Produktlebenszyklus naht. Aber bis dahin ist ja eben auch noch ein Weg zu gehen, für den es ein motiviertes Team braucht. Der Ramp Down eines Produktes gehört schließlich unzweifelhaft auch zur Produktentwicklung. Zu Beginn des Jahres hat XING (bzw. die New Work SE) die durchaus erfolgreichen Produktbereiche XING Events und XING Gruppen eingestellt, um die eigenen Kräfte zu bündeln und den Fokus auf die neu gewählte Strategie zu legen. Ein wirklich mutiger Schritt. Unser heutiger Gast Thomas Gläser, Director Product Experience bei der New Work SE, hat dies hautnah miterlebt und musste (oder wohl besser gesagt "durfte") diese spannende Phase als verantwortlicher Product Leader begleiten. Im Gespräch mit Tim berichtet er, wie er die Motivation für die letzte Produktphase im Team hochgehalten hat und wie er sich selbst dabei gefühlt hat. Eine spannende Diskussion über eine Erfahrung, die nur wenige Produktmenschen machen dürfen. Im Gespräch werden die folgenden Quellen genannt: - Killed by Google (killedbygoogle.com) - Liberating Structures: Ecocycle Planning (liberatingstructures.de/ecocycle-planning/) - Aufräumen mit Methode: Analogie zu Marie Kondo - Buch von Ernest Becker: The Denial of Death Zu dieser Episode passt auch gut diese ältere Folge: - Features wegwerfen - was braucht es dafür außer Mut? Wer mit Thomas Gläser in Kontakt treten möchte, guckt sich am Besten mal seine persönliche Webseite (thomasglaeser.de) an oder folgt ihm auf LinkedIn. Dort teilt er regelmäßig seine Gedanken zu Produktthemen und über die diversen Veranstaltungen auf denen er aktiv ist. Zudem freut sich Thomas zur Kontaktaufnahme auch über eine direkte E-Mail an ich@thomasglaeser.de. Hast du auch schon mal die Erfahrung "Produkt einstellen" gemacht? Welche Überlegungen gab es bei euch? Welche Befürchtungen hattest du, die sich am Ende vielleicht gar nicht eingestellt haben? Wir sind gespannt, von euren Ergebnissen zu hören! 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. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Für Product Owner spielt die tägliche Interaktion mit Softwareentwicklern eine Schlüsselrolle. Sie sind die Stakeholde, mit denen wir im täglichen Arbeiten mit am häufigsten zu tun haben. Von den ganzen Diskussionen über die Absprachen zu Anforderungen bis hin zu gemeinsamen Entscheidungen – die Dynamik dieser Beziehung beeinflusst wesentlich den Erfolg der Produktentwicklung. Um tiefer in diese Beziehung einzutauchen hat Dominique in dieser Folge das Vergnügen, mit Jacob Pawlik (https://www.linkedin.com/in/jacob-pawlik/) zu sprechen. Jacob ist Head of WebTec bei der Scopevisio AG und bringt eine wertvolle Perspektive in unser Gespräch ein: die Erwartungen von Entwicklern an Product Owner. Hauptthemen unserer Diskussion: - Entwicklererwartungen: Was genau erwartet ein Developer von einem Product Owner? Jacob beleuchtet diese Frage aus seiner Erfahrung. - Produktvision: Wie wichtig ist die Produktvision aus der Sicht eines Entwicklers und wie beeinflusst sie die tägliche Arbeit? - Augenhöhe und Hierarchien: Warum sind diese Aspekte entscheidend und wie sollte man mit ihnen umgehen, um eine effektive Zusammenarbeit zu fördern? - Red Flags in der Zusammenarbeit: Jacob teilt seine Einsichten darüber, was in der Zusammenarbeit mit einem Product Owner als Warnsignal gelten kann. - Refinement, Planning und Review: Was braucht ein Product Owner wirklich für diese Prozesse? Was erwartet ein Entwickler in diesen Phasen? - Die Retrospektive mit Product Ownern: Ein Blick auf die Bedeutung und Durchführung effektiver Retrospektiven. - No-Gos für Product Owner: Jacob spricht über häufige Fehler, die Product Owner vermeiden sollten. - Tipps zur Verbesserung der Zusammenarbeit: Abschließend gibt Jacob praktische Ratschläge, wie Product Owner die Zusammenarbeit mit Entwicklern verbessern können. Diese Episode bietet tiefe Einblicke in die Beziehung zwischen Product Ownern und Entwicklern. Wir hoffen, dass ihr diese Folge genauso aufschlussreich findet wie wir. Aber vielleicht habt ihr auch andere Erfahrungen gemacht oder habt eine abweichende Meinung. Lasst es uns gerne wissen. Entweder als Kommentar zum Blogpost dieser Folge oder bei einem der Posts auf Social Media.

Wenn Unternehmen nicht genügend interne Product Owner haben, beauftragen sie zunehmend Interim Product Owner. Meist wird dabei in Form eines zeitlich befristeten Projektauftrags (der idR mehrfach verlängert wird), eine Person gesucht, die als Product Owner woanders schon Erfahrung gesammelt hat. Das beauftragende Unternehmen erhofft sich so Methodenwissen über die Verantwortlichkeit ("Rolle") von außen in die Firma zu bekommen. Aber auch wenn dabei versucht wird, jemanden mit fachlicher Erfahrung des eigenen spezifischen Produktkontexts oder Branche zu finden, gelingt dies nur selten. Denn tatsächlich erscheinen zum einen gar nicht so viele (erfahrene) externe Product Owner verfügbar zu sein - und dass dann auch noch der fachliche Kontext passt, erscheint eher wie ein glücklicher Zufall. Wir haben uns daher Thomas Götten eingeladen, der als Selbständiger solche Aufträge als "Technischer Product Owner" übernimmt. Zum einen will Tim natürlich erstmal verstehen, was das Besondere an einem technischen Product Owner für Thomas ist. Als Product Owner in Festanstellung hatte Thomas viele Jahre Erfahrung sammeln können und ist fest "methodenfest". Das wissen wir, weil wir ihn schon recht lange kennen. Aber vielleicht ist das ja eben auch besonders wichtig, wenn man als Interim Product Owner arbeitet - schließlich darf man sich ja auch nicht vom System des Auftraggebers "verbiegen" lassen, so dass man letztlich als eine Art Zombie Product Owner endet. Es folgt eine spannende Diskussion über Vor- und Nachteile, kein explizites Fachwissen in der Kundendomäne mitzubringen. Natürlich muss man offen und aufgeschlossen sein, aber eine der Schwierigkeiten ist ja allein schon die Akzeptanz bei den Mitarbeitenden beim Kunden. Thomas berichtet von seinen spannenden Erfahrungen bei einem Spielzeughersteller und v.a. aus dem noch ungewöhnlicheren Feld der internationalen Kunstlogistik. Bei einem solch spitzen Produkt stellt sich die Frage nach Externen mit Branchenerfahrung vermutlich noch nicht einmal. Thomas Götten teilt also seine eigenen Learnings aus den letzten Aufträgen als Interim Product Owner und die beiden diskutieren u.a. die folgenden Fragen: Hast man als externer PO die gleichen "Rechte" & "Pflichten" wie ein interner PO? Wie geht man mit "Erbe" um - also wenn ein volles Product Backlog etc. übernommen werden muss, welches man ggf. gar nicht komplett versteht. Wieviel "Invest" in Team, Beziehung etc, lohnen sich, wenn man als Externer unterwegs ist und die Aufträge i.d.R. zwischen 6 und 12 Monaten dauern? Auf diese älteren Episoden unseres Podcasts verweisen Tim und Thomas im Laufe des Gesprächs: - Dein Freund der Scrum Master - Was die Einführung von OKR für Product Owner bedeutet - Wieviel technisches Wissen muss ich als Product Owner haben? - Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner - Event Storming: Verständnis für komplexe Produkte schaffen Wer weitere Fragen an Thomas Götten hat oder mit ihm in Kontakt treten möchte, erreicht ihn am Besten über sein LinkedIn-Profil oder über seine Webseite joettis.com. Hast du schon Erfahrungen mit Interim Product Ownern gesammelt? Wie lief der Einsatz eines zeitlich befristeten Product Owner bei euch ab? Oder warst du wie Thomas selber schon als externer Product Owner ohne Domänenwissen im Einsatz? Wir sind gespannt, von euren Ergebnissen zu hören! 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. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Diesmal wollen wir uns der besonderen Herausforderung der Entwicklung einer Omnichannel widmen. Unser Gast Christoph Herrmann ist Head of Product der Kaufland-App bei Kaufland E-Commerce. Im Gespräch mit Tim gibt er einen Erfahrungsbericht, was die Entwicklung eines digitalen Produkts, also einer App, im Kontext des stationären Handels so besonders macht. Da die App im Rahmen der Omnichannel-Strategie von Kaufland auch im Markt bzw. ganz konkret "am Regal" zum Einsatz kommt, werden hier die Grenzen eines typischen Digitalprodukts deutlich verlassen. Es geht also um sehr unterschiedliche Zielgruppen und die Verzahnung mit den Handelsprozessen in den Märkten. Dies führt natürlich zu besonderen Herausforderungen bei Product Discovery, User Feedback Zyklen usw. und macht eine solche Produktentwicklung schon etwas spezieller. Darüber sprechen Christoph Herrmann und Tim Klein in dieser Folge - nachdem erstmal die Frage geklärt wurde, was überhaupt der Begriff Omnichannel bedeutet. Um folgende Themen geht es danach: Wie laufen Sprint Reviews ab? Wie gelingt die Zusammenarbeit mit Stakeholdern? Sicherlich kann man aus diesen Fragestellungen auch dann wichtige Impulse ziehen, wenn man nicht im Omnichannel-Umfeld unterwegs ist. Zu dieser Episode passt auch gut die kürzlich erschienene Folge "Wieviel technisches Wissen muss ich als Product Owner haben?" Wer weitere Fragen an Christoph Herrmann hat oder mit ihm in Kontakt treten möchte, erreicht ihn am besten über sein LinkedIn-Profil: linkedin.com/in/christophherrmann/ Bist du an der Entwicklung eines ähnlichen Produkts beteiligt? Müsst ihr auch, im Rahmen einer Omnichannel Strategie neben den digitalen Kanälen den stationären Handel im Auge behalten? Welche Herausforderungen sind da bei euch aufgetreten? Wie habt ihr das gut in den Griff bekommen? 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. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Die Integration von UX-Professionals in ein Scrum-Team stellt eine echte Herausforderung dar und erfordert ein tiefes Verständnis für die verschiedenen Charaktere, die in diesem Prozess auftreten können. In dieser Folge spricht Dominique mit Florian Holzhäuser (https://www.linkedin.com/in/florian-holzh%C3%A4user-1429b113b/) von IT Sonix (https://www.itsonix.eu/) über seine Erfahrungen und Erkenntnisse, um diese Herausforderung zu meistern. Florian identifizierte vier mögliche Charaktere, wie UX-Professionals ins Scrum-Team eingebunden werden können: Prediger, Mentor, Macher und Daywalker. Jeder dieser Charaktere bringt unterschiedliche Perspektiven und Fähigkeiten mit sich, die sich auf die Art der Zusammenarbeit im Scrum-Team auswirken können. Der Charakter hängt dabei von verschiedenen Faktoren ab, darunter das verfügbare Budget und die Menge der Arbeit. Der "Prediger" ist jemand, der leidenschaftlich die Bedeutung von UX im Entwicklungsprozess predigt. Dieser Charakter kann dazu beitragen, das Bewusstsein im Team zu schärfen und die Bedeutung einer benutzerzentrierten Herangehensweise zu betonen. Die Integration eines Predigers kann besonders nützlich sein, wenn das Team wenig Erfahrung mit UX hat und einen Anstoß für einen Paradigmenwechsel benötigt. Der "Mentor" spielt eine Schlüsselrolle bei der Anleitung und Schulung des Teams im Bereich UX. Dieser Charakter bringt nicht nur Fachkenntnisse, sondern auch didaktische Fähigkeiten mit sich. Durch den Mentor können Teammitglieder ihre Fähigkeiten im Bereich UX verbessern, was langfristig zu einem selbstständigeren und kompetenteren Team führen kann. Der "Macher" ist jemand, der direkt an den UX-Aufgaben arbeitet und praktische Lösungen liefert. Dieser Charakter ist besonders effektiv, wenn schnelle Ergebnisse erforderlich sind und das Team direkte Unterstützung in der Umsetzung von UX-Praktiken benötigt. Die Integration eines Machers kann jedoch budgetintensiver sein, da möglicherweise mehr Ressourcen benötigt werden. Schließlich gibt es den "Daywalker", der flexibel zwischen den verschiedenen Welten wechseln kann. Dieser Charakter ist anpassungsfähig und kann je nach den Anforderungen des Teams in verschiedene Rollen schlüpfen. Die Integration eines Daywalkers kann die Flexibilität des Teams verbessern und sicherstellen, dass die UX-Professionals nahtlos in den Scrum-Prozess integriert werden. Insgesamt verdeutlicht diese Diskussion, dass die Integration von UX-Professionals in Scrum-Teams nicht nur eine organisatorische Herausforderung ist, sondern auch eine Chance bietet, die Qualität der Produkte durch eine stärkere Fokussierung auf die Benutzererfahrung zu verbessern. Es wird deutlich, dass die Vielfalt der Charaktere innerhalb der UX-Professionals einen positiven Einfluss auf die Agilität und Effektivität von Scrum-Teams haben kann.

Eine Organisation beginnt agil zu arbeiten und benötigt dann Product Owner:innen. Oft werden ehemalige Projektleiter oder Teamleiter als Product Owner:innen bestellt. Dass sich durch diese Veränderung bestimmte Herausforderungen ergeben, liegt nahe. Dies zeigt sich auch in eurem Wunsch, sich einmal über dieses Thema zu unterhalten. Daher sprechen in dieser Folge Dominique und Tim über den Übergang von der alten Verantwortung zur neuen. Im Gespräch wird schnell deutlich, dass es einige Verhaltensweisen gibt, die Projektleiter:innen durchaus hilfreich sein können, aber auch andere, die Schwierigkeiten verursachen. Projektleiter:innen sind oft sehr auf die Auslieferung fokussiert, wobei der Output über dem Outcome steht. Auch die direkte Zuweisung von Aufgaben an Personen mag Projektleiter:innen nützlich sein, aber im agilen Kontext als Product Owner wird dieses Verhalten nicht gut funktionieren. Ähnliches gilt auch für Teamleiter:innen. Die Aufgaben der Personalentwicklung und der Personalbeschaffung fallen schlichtweg weg, sobald man die Verantwortung als Product Owner übernimmt. Das macht den Wandel nicht so einfach. Dabei kann vor allem Transparenz helfen. Damit ist nicht nur die Zusammenarbeit mit dem Team und den Stakeholdern gemeint, sondern auch die persönliche Reflexion. Ehemalige Rollenmuster müssen bewusst umgedeutet werden. Feedbackgeber wie das Team, insbesondere im Rahmen der Retrospektive, und Menschen in der Verantwortung als Scrum Master können dabei hilfreich sein. Diese spielen eine besonders wichtige Rolle, weshalb eine agile Transformation ohne Scrum Master, besonders für Personen aus den vorherigen Rollen als Projektleiter oder Teamleiter, schwierig ist. Dennoch ist eine solche Veränderung gut möglich. Im Gespräch wurde auf folgende Folgen verwiesen: - POEM – Product Ownership Evolution (https://produktwerker.de/poem-product-ownership-evolution-model/) - Sei dein eigenes Produkt! – als PO seine Weiterentwicklung steuern (https://produktwerker.de/sei-dein-eigenes-produkt/) Außerdem erwähnten die beiden noch folgende Quellen: - Das Role Model Canvas (https://www.visual-braindump.de/role_model_canvas/) - Blogpost von Roman Pichler "Be a Balanced Product Leader not a Feature Broker or Product Dictator" (https://www.romanpichler.com/blog/be-a-balanced-product-leader-not-a-feature-broker-or-product-dictator/) - Blogpost von Roman Pichler "Six Types of “Product” Owners” (https://www.romanpichler.com/blog/six-types-of-product-owners/) Wenn ihr selbst aus der Projekt- oder Teamleitung heraus in die Verantwortung als Product Owner gekommen seid freuen wir uns über eure Erfahrungen. Teilt sie gerne im Blogpost zur Folge als Kommentar oder auf unserer LinkedIn-Companyseite als Kommentar. Diese Folge ist übrigens auch unsere Antwort auf eine Frage aus der Community. Wenn auch ihr eine Frage habt, die wir in einer Folge unbedingt mal beantworten sollten, lasst es uns gerne wissen. Schickt dazu gerne eine Mail an feedback@produktwerker.de. Wir freuen uns auf eure Fragen!

Eine Frage, die immer wieder aufkommt, ist die nach dem notwendigen technischen Wissen, dass man in der Verantwortung als Product Owner braucht. Dominique und Tim stellen sich in dieser Folge diese Frage und teilen ihre Erfahrungen sowie ihre Einschätzung dazu. Dazu muss man sich zuerst fragen, warum die Frage nach dem technischen Verständnis eigentlich aufkommt. Das kann einerseits an dem zugang zur Verantwortung als Product Owner liegen. Wenn man vorher in verwandten Rollen wie beispielswerise Business Analyst, oder Softwareentwickler gearbeitet hat, bringt man fast schon natürlich ein technisches Verständnis mit. Das könnte zumindest ein Grund sein, warum viele Product Owner bereits ein solches Verständnis haben und dadurch die Erwartungshaltung ihres Umfeldes entsprechend prägen. Ob das technische Verständnis aber immer hilft ist auch fraglich. Immerhin hat das Team in ihrer Domäne Expertenwissen und so manch ein Product Owner kann nicht aus der eigenen Haut und will mitmischen. Am Ende geht es aber in erster Linie darum, dass die Menschen, die zusammen versuchen ein erfolgreiches Produkt zu entwicklen miteinander sprechen können. Sie müssen sich gegenseitig verstehen. Daher ist ein sehr grundsätzliches technisches Verständnis durchaus hilfreich. Es mus snicht umfangreich sein und ein Informatikstudium ist garantiert zu viel des Guten. Wir haben in dieser Folge auf folgende Folgen verwiesen: - Stellenausschreibungen für Product Owner (https://produktwerker.de/product-owner-stellenausschreibungen/) - Vom Entwickler zum Product Owner (https://produktwerker.de/vom-entwickler-zum-produkt-owner/) - Wie No-Code Tools Produktteams helfen (https://produktwerker.de/no-code-tools/) Darüber hinaus haben wir folgende Quellen genutzt: - Six types of a “product” owners von Roman Pichler (https://www.romanpichler.com/blog/six-types-of-product-owners/) - The Product Trio von Teresa Torres (https://www.producttalk.org/2021/05/product-trio/) - Code it! (Coding Courses for Kids) (https://code-it-studio.de/) Diese Folge ist unsere Antwort auf eine Frage aus der Community. Wenn auch ihr eine Frage habt, die wir in einer Folge unbedingt mal beantworten sollten, lasst es uns gerne wissen. Schickt dazu gerne eine Mail an feedback@produktwerker.de. Wir freuen uns auf eure Fragen!