Die Produktwerker

In 48 Stunden Ideen erproben, Bereichsgrenzen überwinden und neue Arbeitsweisen kennenlernen – Erfahrungen aus der Praxis. Wie können Product Owner Hackathons für ihre Produktentwicklung nutzen? Andrea und Lukas berichten aus ihrer Erfahrung mit der Organisation und Teilnahme bei OBI. Das erfährst du in dieser Folge: - Ablauf: Ideen auf einem Ideation Board sammeln, Teams zusammenstellen und innerhalb von 48 Stunden Prototypen für eine Abschlusspräsentation entwickeln. - Zusammenarbeit: Wie Menschen aus Tech, Märkten und Fachbereichen gemeinsam an Themen arbeiten, die im Alltag an Bereichsgrenzen oder Prioritäten scheitern können. - Rolle der Product Owner: Fokus und Priorisierung einbringen, aber auch bei Tests, Gestaltung oder Präsentationen selbst mitarbeiten. - Nutzen über das Event hinaus: Kontakte knüpfen, neue Fähigkeiten ausprobieren und Arbeitsweisen wie Event Storming in den Alltag mitnehmen. - Umgang mit Ergebnissen: Präsentationen dokumentieren, an zuständige Fachbereiche übergeben und Business Cases sowie den Aufwand für eine produktive Umsetzung prüfen. - Organisation: Mehrere Monate Vorlauf einplanen, Verantwortlichkeiten absichern und früh über Teilnahme, Ideenprozess und Teamfindung informieren. - Rahmenbedingungen: Verpflegung, Pausen und Raum für Austausch als wichtige Bestandteile des Events berücksichtigen. Ein Hackathon liefert nicht automatisch ein fertiges Produkt. Auch Erkenntnisse aus einem Prototyp können wertvoll sein – und manche Ideen werden erst Jahre später wieder aufgegriffen.

Tim & Dominique im Gespräch Tim und Dominique werfen in dieser Folge die Frage auf was passiert, wenn KI unsere Juniors ersetzt und wo dann die Seniors von morgen herkommen. Recherche, Protokolle, Backlog-Pflege und erste Analysen übernimmt eine KI heute schnell und schon recht brauchbar. Genau diese Aufgaben waren lange der Einstieg für Berufsanfänger:innen auf dem Weg hin zum Product Owner oder Product Manager (genauso in der Projektarbeit). Solche zuarbeitenden Aufgaben und Rollen boten Gelegenheit, eine Fähigkeit nach und nach zu durchdringen, Fehler zu machen und zu beobachten, wie andere auf Basis der eigenen Arbeit entscheiden. Fällt dieser Einstieg weg, bleibt offen, wie Erfahrungen im Berufseinstieg überhaupt erworben werden kann. Irgendwann gehen dann die heutigen Seniors in Product Leadership und C-Level (oder auch in Rente). Und was passiert dann? Senior wird niemand durch die nächste Weiterbildung. Erfahrung wächst durch viele kleine Entscheidungen, durch Feedback und durch Fehler. Man kann sie weder herunterladen, noch per Knopfdruck abrufen. Das Wissen dahinter ist implizit, ähnlich wie beim Fahrradfahren, denn wer das Gleichgewicht hält, kann kaum erklären, wie er das macht. Mit explizitem Wissen geht eine KI natürlich souverän um. Sobald Menschen zusammenarbeiten, braucht es aber ein Gespür für Kontext, für Konflikte mit und zwischen Stakeholdern und dafür, Unsicherheit auszuhalten. Dazu kommt ein leicht zu übersehendes Risiko: Wer neu im Beruf ist, erzeugt mit KI in kurzer Zeit User Stories, Konzepte, Interview-Leitfäden und Protokolle, die erstaunlich gut aussehen mögen. Ob sie taugen, beurteilt nur, wer solche Arbeit schon einmal selbst gemacht hat. Der Automation Bias verschärft das Problem nochmal, denn Menschen vertrauen automatisierten Ergebnissen schnell und prüfen sie zu selten. Brüche und offene Schnittstellen fallen dann spät auf und kosten richtig Geld. Wenn KI unsere Juniors ersetzt, braucht es einen neuen Weg, um Erfahrung aufbauen zu können. Der Ausweg liegt im Wechsel von der Produktionskompetenz zur Entscheidungskompetenz auf Basis von Urteilsvermögen. Ein Ansatz könnte der folgende sein: Berufseinsteiger bekommen besser echte, klar abgesteckte Probleme statt billiger Zuarbeitsaufgaben. Sie nutzen die KI als Werkzeug, begründen ihre Entscheidungen und vergleichen Alternativen. Die Verantwortung wächst Schritt für Schritt, ähnlich wie bei Delegation Poker: erst beobachten, dann mitreden, schließlich selbst entscheiden. Dafür eignen sich kleinere Produkte mit wenigen Stakeholdern. Zwei Jahre als Junior abzusitzen und nur AI-Tools zu bedienen, garantiert dagegen keine Reife. Damit verändert sich die Rolle von Seniors und Führungskräften. Unser Rat: Sie delegieren nicht alle lästige Aufgaben und machen stattdessen ihr Denken sichtbar. Sie fragen die Juniors, warum eine Lösung gut ist, welche Alternativen existieren und was dagegen spricht und sie erklären ihre eigenen Entscheidungen ganz explizit. Das kostet natürlich Zeit, denn über ein Ergebnis nachzudenken dauert länger, als es zu erzeugen. Die Juniorphase wird kürzer, das Mentoring dafür intensiver. Organisationen müssen Nachwuchsentwicklung deshalb als bewusste Investition begreifen, auch wenn der wirtschaftliche Druck zu kurzfristiger Produktivität drängt. Juniors werden nicht verschwinden, es wird sich lediglich ihr Einstieg verändern. Statt kleiner Aufgaben bekommen sie Entscheidungsräume und dazu Reflexionsräume, in denen sie mit erfahrenen Kolleginnen und Kollegen auswerten sollten, was funktioniert hat. Die Leitfrage für jedes Unternehmen lautet daher: Wer ist in drei bis fünf Jahren unser Senior? Folgende ältere Episoden unseres Podcasts passen zu diesem Thema: Karrierepfad als Product Owner Sei dein eigenes Produkt! – als PO seine Weiterentwicklung steuern Wird KI via Automatisierung den Einsteigern wichtige Erfahrungen rauben und dadurch das Wachstum bzw. die Lernreise von Juniors behindern? Oder meint ihr, dass sich eigentlich nicht so viel ändern wird? Teilt eure Gedanken zu diesem Thema doch gerne mit uns und der Community. Hinterlasse gerne einen Kommentar unterm Blog-Artikel oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Oliver & Tim im Gespräch Oliver und Tim sprechen in dieser Folge über ein Problem, das vermutlich viele Product Owner kennen: Das Team arbeitet dauernd an Stories, die gar nicht wichtig sind. Der Anlass ist ein Coachingfall. Ein Produktmensch klagt darüber, kaum voranzukommen. Sein Team hat immer zu viel zu tun. Gleichzeitig schreiben die Teammitglieder eigene Tickets ins Backlog. Oder sie ziehen sich Themen selbst von irgendeiner Stelle des Backlog. Manche Stories laufen auch gerne über mehrere Sprints weiter, ohne dass die Developer ein Störgefühl zeigen. Nur passt das selten zur eigentlich notwendigen Produktstrategie des Product Owners bzw. der Produktorganisation. Wenn Teammitglieder selbst Einträge für das Product Backlog schreiben, ist das natürlich erstmal ein absolut gutes Zeichen. Es zeigt echte Selbstorganisation. Schwierig wird es dort, wo diese Einträge ohne Absprache direkt ins Backlog wandern und die Reihenfolge verändern. Genau diese Reihenfolge liegt eigentlich in der Verantwortung der Produktverantwortlichen. Fehlen klare Working Agreements, wer Tickets erstellt und wer sie freigibt, entsteht schnell Unordnung im Backlog. Stories, die gar nicht wichtig sind, bleiben oft über mehrere Sprints liegen. Man möchte begonnene Arbeit ja zu Ende bringen… Das klingt vordergründig vernünftig, kostet aber Steuerungsmöglichkeit. Ein hilfreicher Reflex: Unfertige Einträge wandern konsequent zurück ins Product Backlog. So bleibt die Priorisierung nach Wert erhalten. Die Produktverantwortliche soll dann jederzeit neu entscheiden können, welche Themen gerade wichtiger sind. Hinter dem Punkt "Stories die gar nicht wichtig sind" stecken oft andere Gründe. Häufig fehlt eine klare Produktvision. Technisch geprägte Teams setzen dann eigene (ggf. technische) Prioritäten, weil niemand ihnen die Richtung von oben deutlich genug vermittelt hat. Aber auch andersrum mag technische Komplexität eine Rolle spielen: manche Produktverantwortliche durchdringen die technischen Zusammenhänge nicht gut genug bzw. schaffen es nicht, die fachlichen Zusammenhänge und Notwendigkeiten dem Team gut genug zu vermitteln. Entwicklerinnen und Entwickler treffen dann lieber eigene, technisch motivierte Entscheidungen - schlichtweg weil ihnen der Kontext fehlt. Fehlt zusätzlich eine Scrum Masterin bzw. Agile Coach moderiert oft niemand die nötigen Retrospektiven. Genau dort sollten solche Muster eigentlich auffallen. Auch geringe Präsenz der Produktverantwortlichen im Teamalltag begünstigt die Entwicklung. In dieser Lücke entstehen eigene Gewohnheiten und stille Freiheiten. Fehlendes Refinement und fehlende Sprintziele verstärken den Effekt zusätzlich. Ohne Sprintziel wird im Sprint Planning nie klar, warum ausgerechnet diese eine Story gerade wichtiger sein sollte als jene andere. Am Ende hilft nur Konsequenz: solche Beobachtungen dürfen nicht folgenlos bleiben. Sie brauchen Raum in Retrospektiven, im Refinement und im Sprint Planning. Dazu gehört auch eine Produktvision, die man immer wieder neu erzählt, bis sie beim ganzen Team ankommt (oder allen gefühlt schon zu den Ohren rauskommt). Wer also merkt, dass im eigenen Team dauernd an Stories gearbeitet wird, die gar nicht wichtig sind, sollte das als Alarmsignal für den gesamten Produktentwicklungsprozess verstehen. Oliver und Tim ermutigen dazu, dieses Storytelling auch mit Werkzeugen künstlicher Intelligenz auszubauen. So lässt sich die eigene Produktstrategie in einer Sprache aufbereiten, die im Entwicklungsteam wirklich verfängt. Folgende frühere Episoden werden im Gespräch genannt: Wenn dein Team dir als Product Owner nicht folgt Mit Storytelling andere von deinen Produktideen überzeugen Product Backlog Refinement - Tipps für Product Owner Product Principles (Produktprinzipien) Verantwortung als Product Owner übernehmen Arbeitet euer Team auch dauernd an Stories, die gar nicht wichtig sind? Dann wartet nicht länger und sprecht das offen in eurer nächsten Retrospektive an. Klärt gemeinsam Working Agreements für euer Product Backlog und teilt eure Gedanken doch mit uns und der Community. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Philipp Weiß im Gespräch mit Oliver Worum es geht Ausgangspunkt war ein Gespräch auf den Product Owner Days in Köln. Im Workshop von Tim Herbig zum Thema „Von Strategie zu Zielen“ tauchte immer wieder dieselbe Frage auf: Worauf beziehen sich Strategie, Vision und North Star Metric eigentlich? Wenn die gesamte Website das Produkt ist, bleibt eine Produktvision so allgemein, dass sie kaum hilft. Auch eine North Star Metric bleibt dann auf Ebene von Visits oder Nutzern. Wird dagegen ein Teilaspekt wie die Datenpflege als Produkt gedacht, sind ganz andere Kennzahlen möglich, etwa eingegangene Korrekturen pro Tag. Transfermarkt in Kürze Transfermarkt wurde im Jahr 2000 gegründet und ist die größte öffentlich zugängliche Fußballdatenbank der Welt. Die Daten entstehen nach dem Wikipedia-Prinzip: Nutzer:innen reichen Korrekturen ein, meist ehrenamtliche Kräfte prüfen sie. Dazu kommen Marktwerte, News, ein großes Forum, Tools und Spiele, ein Premium-Angebot für Spielerberateragenturen und eine Datenschnittstelle für Vereine. Das Ganze läuft in 16 Sprachen auf 27 Domains, ergänzt um App und über 70 Social-Kanäle. Auffällig ist der saisonale Effekt: Am stärksten ist Transfermarkt, wenn kein Fußball gespielt wird, also in der Transferzeit und am Deadline Day. Vier Wege, das Produkt zu schneiden • Nach Kanal (Website, App): technisch naheliegend und effizient, weil Teams mit ähnlichem Skillset zusammenarbeiten. Inhaltliche Themen betreffen aber meist beide Kanäle, und die Nutzererfahrung sollte sich ähneln, auch wenn sie nicht identisch ist. Oliver bringt dazu ein Beispiel aus dem Alltag: Ein Download-Hinweis aus dem Podcast-Hosting führte in die App, wo es den Download gar nicht gab. • Nach Inhalt: etwa Statistik, Datenpflege und Community, Content und News, Gaming und Tools, B2B. Das ist konkreter als „die Website“, würde bei Transfermarkt aber fünf bis sechs Teams erfordern, die jeweils eigene Vision, Ziele und Roadmap entwickeln. • Nach Teamstruktur: Wer interdisziplinär arbeiten will, kommt bei den vorhandenen Ressourcen auf etwa zwei Teams. Dann bleibt am Ende wieder die Website das Produkt. • Nach Nutzerbedürfnissen: nachschlagen, Fußball verfolgen, diskutieren und beitragen, Transfermarkt beruflich nutzen. Diese Variante würde Philipp aktuell am ehesten weiterverfolgen, weil sie Priorisierung deutlich erleichtert. Wichtig ist Oliver dabei: Product Owner haben einen Freiheitsgrad, das Produkt so zu definieren, wie es den größten Nutzen bringt. Jede Wahl zieht aber Konsequenzen für Metriken, Teamzuschnitt und Zusammenarbeit nach sich und lässt sich nicht allein treffen. Bei Transfermarkt wäre es eine Entscheidung im Kreis von drei bis fünf Personen inklusive Geschäftsführung. Priorisierung und die Schwierigkeit, Dinge abzuschalten Im aktuellen Backlog konkurrieren Erweiterungen des Berater-Premium-Angebots mit neuen Filtern in der Statistik. Diese Dinge haben unterschiedliche Flughöhen, und Features mit direktem Umsatz lassen sich kaum fair mit anderen vergleichen. Ein Produktschnitt ist deshalb immer auch eine Priorisierungsentscheidung, weil er festlegt, wie viele Menschen an welchen Themen arbeiten. Dazu kommt ein gewachsener Feature-Bestand. Beim Ground-Hopping-Tool und beim Managerspiel war ein Abschalten zeitweise im Gespräch. Beim Managerspiel musste montags nach dem Bundesliga-Spieltag ein Techniker mehrere Jobs von Hand starten. Statt es abzuschalten, gab es einen Kraftakt, seitdem läuft es weitgehend von selbst. Mit Emotionen, auch bei den eigenen Mitarbeitenden, fällt der Abschied schwer, und selbst zehn Nutzer am Tag sind mehr als keine. Oliver hält dagegen: Wer sich von Dingen trennt, nimmt Komplexität aus dem Produkt, und die Produktdefinition wird einfacher. Fokus statt Vollständigkeit Philipps Wunschszenario: Das Unternehmen verständigt sich gemeinsam darauf, zwei Spielfelder für die nächsten zwölf bis achtzehn Monate wirklich zu verbessern und sich konsequent darauf zu konzentrieren. Oliver zieht die Verbindung zu Playing to Win: Das Spielfeld wird begrenzt, offen bleibt noch, wie dort gespielt und gewonnen wird. Wer so fokussiert, für den ist die Ebene des Produktschnitts womöglich gar nicht mehr so entscheidend. Zusätzlich beschreibt Philipp eine Herausforderung in den Köpfen: Nach 26 Jahren Website ist es für viele Stakeholder nicht leicht, App und Website als unterschiedliche Dinge zu denken. Viele Kolleg:innen, die mit dem Produkt arbeiten, etwa in Redaktion, Datenpflege oder Beratergeschäft, bringen zudem eigene Ideen und Wünsche mit. Ein Rat für Product Owner in ähnlichen Situationen Über den eigenen Tellerrand schauen, Methoden und Frameworks kennenlernen und überlegen, wie sie sich auf das eigene Produkt anwenden lassen. Daraus entstehen kritische Fragen an das eigene Unternehmen, und am Ende gehören harte Diskussionen mit dem Management dazu. Das darf laut Philipp auch ein bisschen wehtun. Erwähnt in der Folge • Transfermarkt.de • Product Owner Days, Köln • Playing to Win (Roger Martin) Fazit Wer das Produkt nicht klar definiert, tut sich mit Vision, Metriken und Priorisierung schwer. Die Definition lässt sich meist nicht allein treffen und hat Konsequenzen für Teams und Zusammenarbeit. Umso wichtiger ist es, sie transparent und für alle Beteiligten klar zu machen, auch wenn das unbequem ist. Clarity over Comfort.

Oliver & Dominique im Gespräch In dieser Folge sprechen Dominique und Oliver über das Tracken von Nutzungsverhalten. Dabei geht es darum, warum Produktdaten oft ehrlicher sind als das, was Menschen in Interviews erzählen. Wer Nutzende befragt, bekommt wertvolle Eindrücke, aber auch gefärbte Antworten, denn kaum jemand zeigt sich gerne von einer schwachen Seite. Das Tracken von Nutzungsverhalten liefert die quantitative Ergänzung und zeigt, was im Produkt tatsächlich passiert. Diese Lücke begegnet Produktteams ständig, gerade beim Prüfen von Hypothesen aus der Product Discovery. Nicht jede Funktion braucht die gleiche Tiefe an Beobachtung. Bevor Teams Events, Klicks oder Feldänderungen erfassen, sollten sie klären, welche Entscheidung die Daten unterstützen sollen. Eine Terminverwaltung kann etwa festhalten, wie oft Termine angelegt, verschoben oder abgesagt werden, ohne jede einzelne Eingabe zu protokollieren. Tracking funktioniert am besten, wenn zuerst der gewünschte Outcome feststeht und daraus passende Kennzahlen abgeleitet werden. Verbindet man einzelne Ereignisse über eine Sitzung hinweg, werden Nutzungswege sichtbar. So lässt sich erkennen, wo Menschen aussteigen oder welche Muster sich wiederholen. Im Onlinehandel zeigt ein Funnel beispielsweise, an welchem Schritt des Bestellprozesses Kundschaft abspringt. Auch Kohorten helfen als Unterteilung, um so beispielsweise Unterschiede zwischen neuen und langjährigen Nutzenden zu verstehen. Natürlich gibt es einige Herausforderung beim Tracken: Problematisch wird es, wenn Teams zunächst möglichst viele Daten sammeln und erst danach nach passenden Fragen suchen. Ebenso riskant ist es, Daten nur zur Bestätigung bereits getroffener Entscheidungen auszuwählen. Beides erzeugt Kennzahlen, aber kaum belastbare Erkenntnisse. Auch intensive Nutzung bedeutet nicht automatisch Mehrwert. Sie kann ebenso auf umständliche Bedienung hinweisen. Korrelationen erklären zudem keine Ursachen, und aggregierte Kennzahlen können Unterschiede zwischen Nutzergruppen verdecken. Daten müssen deshalb immer im jeweiligen Kontext interpretiert werden, etwa unter Berücksichtigung saisonaler oder externer Effekte. Entscheidend ist am Ende, ob Tracking tatsächlich Entscheidungen verändert. Werden Daten regelmäßig erhoben, aber nie genutzt, lohnt sich der Aufwand kaum. Dominique und Oliver zeigen anhand vieler Beispiele, dass gute Produktentscheidungen meist aus der Kombination qualitativer und quantitativer Erkenntnisse entstehen. Gezielt eingesetztes Nutzungstracking unterstützt damit eine evidenzbasiertere Produktarbeit. Mehr unter: https://produktwerker.de/tracken-von-nutzungsverhalten/

Tim & Dominique im Gespräch In vielen Unternehmen kann man erleben, dass Menschen sich Product Owner nennen, obwohl ihr Team längst kein Scrum mehr lebt. Aber verdient ein Product Owner ohne Scrum überhaupt noch diesen Namen? Oder verliert der Titel dann seine Grundlage? In Trainings und Organisationen tauchen diese Fragen immer wieder auf. Die Rolle heißt dort dann oft weiterhin Product Owner, im Alltag bestimmt aber längst Kanban oder ein eigenes, vielleicht sogar informelles Vorgehen das Bild. Historisch wurde der Begriff Product Owner durch Scrum verbreitet und bekannt. Zusätzlich taucht er im Scaled Agile Framework auf, dort allerdings mit einer anderen Bedeutung als im ursprünglichen Scrum Guide. Verschwindet Scrum aus einer Organisation, bleibt die Bezeichnung trotzdem oft bestehen. Sie hat sich auch im deutschsprachigen Recruiting fest etabliert. Menschen suchen nach wie vor deutlich häufiger nach Product Owner als nach Product Manager. Der Rollenname überlebt also das Framework, aus dem er stammt. Wechselt ein Team beispielsweise zu Kanban, lässt sich die Rolle Product Owner meist einfach weiterführen. Kanban selbst lässt offen, wer Prioritäten setzt und Entscheidungen trifft. Schwieriger wird es, wenn mit Scrum auch die Rituale verschwinden. Dabei geben diese Rituale einer Person erst die Möglichkeit, Produktverantwortung wirklich wahrzunehmen. Ohne Sprint Review fehlt der regelmäßige Moment für Feedback und Kurskorrektur. Ohne Retrospektive fehlt der Raum für die Weiterentwicklung der eigenen Zusammenarbeit. Und ohne ein sauber priorisiertes Product Backlog tauchen schnell wieder Listen auf, in denen fast alles gleich wichtig erscheint. An genau diesen fehlenden Kadenzen zeigt sich, wie viel von der ursprünglichen Rollenidee verloren geht, sobald ein Product Owner ohne Scrum arbeiten muss und nichts Vergleichbares an dessen Stelle tritt. Zwischen Product Owner als Rollenbezeichnung und Product Ownership als eigentlicher Produktverantwortung liegt ein wichtiger Unterschied. Product Ownership beschreibt, wie viel Entscheidungsgewalt, Kundennähe und Gestaltungsspielraum ein Mensch oder ein ganzes Team für den Erfolg eines Produkts übernimmt. Das gilt unabhängig vom Framework und unabhängig vom Titel auf der Visitenkarte. Werkzeuge wie das Product Ownership Evolution Model oder eine klassische RACI Matrix machen diese Verantwortung sichtbar, statt sie stillschweigend vorauszusetzen. Wer offen mit Führungskräften und Stakeholdern klärt, wie viel Ownership das Unternehmen tatsächlich überträgt, gewinnt echte Klarheit. Das gilt ganz gleich, ob am Ende Scrum, Kanban oder gar kein Framework im Hintergrund steht. Fehlt diese Klarheit, ziehen sich viele Menschen in vertraute Muster zurück und aus ihnen werden reine Verwalter des Backlogs, obwohl der Titel eigentlich Gestaltung verspricht. Diese Lücke zwischen Erwartung und gelebter Rolle erzeugt bei Betroffenen häufig eine stille Unsicherheit. Besonders dann, wenn eine Organisation den Rollenwechsel nie bewusst und offen kommuniziert hat. Manche Unternehmen begegnen dieser Unschärfe mit einem neuen Namen, etwa Product Lead oder Head of Product. Ein neues Etikett allein schafft dabei aber noch keine Rollenklarheit. Solange niemand Entscheidungsbefugnisse, Erwartungen und den Zugang zu Kundinnen und Kunden ausdrücklich benennt, verändert sich wenig. Dominique und Tim geben eine Empfehlung an alle, die sich in genau dieser Situation wiederfinden: Die Frage nach dem passenden Titel tritt in den Hintergrund, sobald echte Klarheit über Entscheidungsrechte, Erwartungen und Handlungsspielräume entsteht. Wer als Product Owner ohne Scrum arbeitet, sollte diese Klarheit aktiv im eigenen Umfeld einfordern. Sonst bleibt oft nur die stille Anpassung an einen unpassenden Titel. Ob am Ende der Titel Product Owner bleibt oder eine andere Bezeichnung ihn ablöst, verliert dadurch spürbar an Bedeutung.

Lilith Brockhaus im Gespräch mit Tim Lilith Brockhaus spricht in dieser Folge mit Tim über das AI Operating System. Lilith war bereits vor über drei Jahren zu Gast hier im Podcast, damals ging es um visuelle Entwicklungswerkzeuge ohne Programmierkenntnisse (NoCode bzw. LowCode). Seitdem hat sich bei ihr viel verändert. Mit der neuen Marke O/WONDER beschäftigen sie und ihr Team bei VisualMakers sich jetzt mit agentischer Wissensarbeit. Genau darum dreht sich das Gespräch in dieser Folge: Wie baut man ein eigenes AI Operating System für die eigene Organisation auf, was ist ein AI OS überhaupt und warum lohnt sich das gerade für Product Owner? Ein Operating System, unabhängig von AI, ist das Betriebssystem einer Organisation, vergleichbar mit dem Betriebssystem eines Smartphones oder Macbooks, das die Apps verbindet, ihr Zusammenspiel sicherstellt und im Hintergrund alles zusammenhält. Ein AI Operating System überträgt dieses Prinzip auf eine Organisation. Es macht die DNA eines Unternehmens zugänglich und explizit nutzbar, also die Ziele, Prozesse und Werte, die sonst oft nur implizit vorhanden sind. Tim vergleicht es mit einem Notebook, dessen Betriebssystem die Hardware erst bedienbar macht. Übertragen auf KI heißt das für ihn: Ein Operating System macht das Sprachmodell in einer Organisation erst wirklich einsetzbar, für die eigene Arbeit oder für das gesamte Unternehmen. Ein AI Operating System besteht laut Lilith Brockhaus aus vier Ebenen. Die Basis bildet der Wissenslayer mit Zielen, Prozessen und dem Kontext einer Organisation. Darauf folgt die Systemebene mit den Werkzeugen, in denen Daten entstehen, etwa ein Product Management System oder ein CRM. Die dritte Ebene ist die Ausführung. Hier legt das Team fest, welche Aufgaben die KI eigenständig übernehmen darf, zum Beispiel das Schreiben von Tickets nach einem festen Format. Ganz oben liegt, als vierte Ebene, die Oberfläche, also die Touchpoints, über die Menschen mit dem System sprechen, sei es im Chat, in Slack o.ä. oder direkt im Fachtool. Das Sprachmodell selbst bleibt dabei austauschbar und ist nur die Engine hinter dem eigentlichen System. Lilith beschreibt den Wissenslayer in der Folge als wachsende Bibliothek. Ständig kommen neue Bücher dazu, und ein gutes Verzeichnis sorgt dafür, dass Mensch und KI finden, was sie suchen. KI erkennt Muster in Sprache besonders gut. Dadurch lassen sich auch bisher implizite Entscheidungen sichtbar machen, etwa das Bauchgefühl bei der Priorisierung eines Features. Darin ist auch eine Nähe zu Product Principles und zum Double Loop Learning erkennbar. Dabei trifft eine Organisation nicht nur einzelne Entscheidungen, sie entwickelt auch ihre Entscheidungsregeln selbst weiter. Für den Einstieg mit einem AI Operating System empfiehlt Lilith etwas Pragmatisches. Meetings oder Gespräche mit Stakeholdern transkribieren und sich von der KI nach wenigen Wochen zeigen lassen, welche Muster sie darin erkennt. Als erste Basisdateien nennt sie drei Dinge, den Zweck des Unternehmens, das Ideal Customer Profile und eine Beschreibung des eigenen Angebots. Bei O/WONDER aktualisiert sich das Ideal Customer Profile automatisch anhand anonymisierter Vertriebsgespräche und wächst so mit jedem echten Kundenkontakt weiter. Für die Versionierung setzt das Team auf Git. Das gesamte Unternehmenswissen wird dort wie Code behandelt, inklusive der Nachvollziehbarkeit von Änderungen. Für Product Owner gibt es zwei Rollen in diesem Zusammenspiel. Auf der einen Seite bleibt viel Raum für Stakeholdergespräche, Empathie und Entscheidungen, die ein AI Operating System nicht abnehmen kann. Auf der anderen Seite braucht es Menschen, die genau dieses System bauen, pflegen und mit neuem Kontext füttern. Tim und Lilith sind sich einig: Dafür sind Mut und Neugier nötig, gerade weil viele Organisationen noch am Anfang stehen und es kein fertiges Rezept gibt. Wer selbst ausprobieren möchte, wie ein AI Operating System die eigene Arbeit verändert, findet bei Lilith und O/WONDER einen guten Startpunkt für die ersten Schritte. Folgende frühere Episoden des Podcasts empfehlen wir rund um das aktuelle Thema: Wie No-Code Tools Produktteams helfen können Was kann AI im Produktmanagement heute schon wirklich? Produktentwicklung mit einem agentischen Team (BMad, GSD, Superpowers …) Wenn Du weitere Fragen an Lilith Brockhaus hast oder direkt mit ihr in Kontakt treten möchtest, erreichst Du sie am besten über ihr LinkedIn-Profil oder die neue Brand Page O/WONDER. Weitere Infos zum vorgestellten AI Operating System erhältst du auf der speziellen Landingpage zum AI Operating System. Hast du schonmal von AI Operating Systems gehört? Siehst du darin die Zukunft der Arbeit mit AI oder bleibst du eher skeptisch? Teilt eure Gedanken doch mit uns und der Community. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Dominique & Oliver im Gespräch In dieser Folge sprechen Oliver und Dominique über Product Backlog Priorisierung in einer Zeit, in der Aufwand als Bremse mehr und mehr als Kriterium verschwindet. Wenn KI Agenten Features nahezu ohne Realisierungsaufwand bauen, verliert das klassische Rechenspiel aus Wert geteilt durch Aufwand seine Grundlage. Genau diese Verschiebung nehmen die beiden zum Anlass, gängige Priorisierungsmethoden neu zu hinterfragen und erklären, was sich dabei in der Welt der Product Owner verändert. Viele bekannte Priorisierungsformeln setzen Aufwand in den Nenner. Das gilt für den klassischen Vergleich von Wert und Aufwand genauso wie für Ansätze wie Weighted Shortest Job First (WSJF). Überall steckt die Annahme drin, dass Entwicklungszeit eine knappe Ressource bleibt. Sinkt der Aufwand durch KI gestützte Entwicklung Richtung Null, verlieren diese Formeln ihre Rechengrundlage. Product Backlog Priorisierung braucht dann andere Kriterien, denn eine Reihenfolge bleibt trotzdem nötig. Selbst mit vielen parallelen Agents entstehen Abhängigkeiten zwischen Ergebnissen, die eine Sortierung weiterhin erzwingen. Ohne Aufwand als Korrektiv droht das Product Backlog zur reinen To do Liste einer reinen Product Delivery zu werden. Alles, was sich schnell umsetzen lässt, wird dann einfach abgearbeitet. Matt LeMay beschreibt in seinem Buch "Impact-first Product Teams" genau diese Gefahr der sog. "Death Spiral". Viele kleine, wirkungsarme Dinge machen ein Produkt am Ende schwerer wartbar und schwerer weiterentwickelbar. Wer sich nur auf kleine, billig gebaute Dinge konzentriert, ohne vorher zu klären, ob sie überhaupt Wert erzeugen, verliert genau diese Fähigkeit. Die eigentliche Frage lautet nicht, was sich bauen lässt, sondern was es wert ist, gebaut zu werden. Als Ersatz für Aufwand bringt Oliver einen Artikel von Jeff Gothelf ins Gespräch. Der Titel lautet How to prioritize your backlog when effort is no longer the constraint. Gothelf schlägt zwei Kriterien vor, die in bestehenden Priorisierungsformeln einfach die Spalte für Aufwand ersetzen können. Das erste Kriterium ist der Lernwert, also wie viel Erkenntnis die Umsetzung eines Backlog Items über Nutzerinnen, Markt oder Technik bringt. Das zweite Kriterium ist die Umkehrbarkeit, angelehnt an Jeff Bezos bekannte Unterscheidung zwischen leicht rückgängig zu machenden und kaum revidierbaren Entscheidungen. Aus beiden Achsen entsteht eine Matrix mit vier Feldern, die ganz unterschiedliche Umgänge mit Backlog Einträgen nahelegt. Hoher Lernwert und leichte Umkehrbarkeit markieren den Bereich, in dem sich schnelles, KI gestütztes Bauen besonders lohnt. Hier reicht es, zu bauen, zu messen und bei Bedarf wieder zurückzudrehen. Hoher Lernwert bei schwerer Umkehrbarkeit verlangt dagegen mehr Vorsicht. Oliver und Dominique sprechen über kleinere Spikes, Prototypen oder Fake Door Tests. Diese liefern genau den hohen Lernwert und lassen sich trotzdem leicht wieder zurücknehmen. Niedriger Lernwert kombiniert mit schwerer Umkehrbarkeit gilt beiden als das heikelste Feld überhaupt. Bleibt der Lernwert niedrig und die Entscheidung leicht umkehrbar, lohnt sich meist ein schneller Versuch ohne großen Abstimmungsaufwand. Gerade weil Bauen so günstig wird, gibt es die Gefahr von unreflektierten, teuren Entscheidungen. Wie schmerzhaft eine Umkehrung tatsächlich ausfällt, lässt sich selten allein am Schreibtisch beurteilen. Diese Einschätzung gelingt nur im Gespräch mit denjenigen, die Architektur und technische Realisierung im Detail kennen. Politische oder hierarchische Diskussionen um laute Stimmen und große Budgets lösen die beiden Kriterien ohnehin nicht auf. Sie verschieben aber den Fokus dieser Gespräche weg vom Aufwand hin zu Lernwert und Rückabwicklungsfähigkeit. Genau das verändert nach Einschätzung der beiden auch den Ton solcher Diskussionen. Für den eigenen Alltag schlägt Oliver einen kleinen Praxistest vor. Statt Aufwand sollen Teams im nächsten Backlog Refinement testweise Lernwert und Umkehrbarkeit gemeinsam bewerten, egal auf welcher Skala. Urteilsvermögen wird dadurch zu einer knappen Ressource. Ob sich der Bau eines Backlog Items überhaupt lohnt, bleibt eine Entscheidung, die Product Owner weiterhin selbst treffen müssen. Wie einfach eine KI die Umsetzung macht, spielt für diese Entscheidung keine Rolle. Product Backlog Priorisierung verschiebt sich damit von einer Rechenaufgabe zu einer bewussten Reflexion über Wert, Lernen und Risiko. Folgende ältere Episoden stehen in Bezug zu dieser Folge: Wie kann ich als Product Owner objektiv priorisieren? Fake Door Tests einfach und schnell umsetzen Habt ihr das Kriterium Umkehrbarkeit schon einmal bewusst in eure Priorisierung einfließen lassen? Vielleicht kennt ihr aus eurem Alltag als Product Owner oder Product Ownerin sogar noch ganz andere Größen, die den klassischen Aufwand ersetzen könnten, sobald KI das Bauen selbst zur Nebensache macht. Teilt eure Erfahrungen doch mit uns und der Community. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Oliver & Dominique im Gespräch In dieser Folge sprechen Oliver und Dominique über die fünf Funktionen von Produktvisionen. Sie erklären, warum viele Teams ihre Vision nach der Erstellung schlicht vergessen. Dominique begleitet seit vielen Jahren Produktteams als Coach und Trainer. Dabei hat er sich intensiv mit der Frage beschäftigt, was eine Produktvision eigentlich leisten muss, damit sie im Alltag wirkt. Genau darum dreht sich das Gespräch. Es geht nicht um die Erstellung eines Vision Statements, sondern um die Funktionen, die eine Vision danach erfüllen sollte. Am Anfang steht das Klären. Bevor ein Team eine knackige Formulierung sucht, muss es einiges klären. Für wen baut es das Produkt, welches Problem löst es dabei und unter welchen Bedingungen entsteht daraus Wert? Teams gehe hier oft zu schnell über konkrete Menschen hinweg. Stattdessen bemühen sie abstrakte Zielgruppen wie junge Erwachsene mit mittlerem Einkommen. Solche Beschreibungen helfen bei Entscheidungen kaum weiter. Wer dagegen über echte Bedürfnisse, Nutzungskontexte und die eigenen Organisationsziele spricht, schafft eine Basis für spätere Entscheidungen. Aus dem Klären wird noch keine Vision. Dafür braucht es die zweite Funktion, das Verdichten. Ein Team führt die gesammelten Erkenntnisse, Wünsche und teils widersprüchlichen Meinungen zusammen und wählt daraus eine gemeinsame Richtung aus. Verdichten bedeutet nicht, alles unterzubringen, sondern sich für eine Richtung zu entscheiden. Am Ende dieser Phase steht meist ein Satz oder ein Bild, das als Erinnerungsanker dient. Es hilft dem Team, sich immer wieder klarzumachen, wofür es eigentlich arbeitet. Damit dieser Anker im Alltag ankommt, braucht es die dritte Funktion: das Übersetzen. Eine Vision allein lässt praktisch jede Entscheidung zu, weil sie meist viel zu weit weg vom operativen Geschäft formuliert ist. Oliver und Dominique sprechen deshalb über die Verbindung zwischen Produktvision, Produktstrategie, Zielen und Roadmaps. Erst wenn eine Strategie erkennbar auf die Vision einzahlt und daraus ein Product Goal abgeleitet wird, entsteht eine Brücke. Sie verbindet den Alltag mit der langfristigen Richtung. Ohne diese Übersetzung bleibt die Vision ein hübscher Satz ohne Wirkung auf reale Entscheidungen. Die vierte Funktion, das Anwenden, prüft, ob die Vision tatsächlich in echten Produktentscheidungen sichtbar wird. Das betrifft die Priorisierung im Backlog, Gespräche in der Discovery, Sprintziele und die Einleitung eines Reviews. Hält sich ein Team an seine Vision, wenn ein wichtiger Termin, ein Wettbewerber oder ein großer Kunde Tempo verlangt? Genau in solchen Momenten zeigt sich, ob eine Vision wirklich handlungsleitend ist oder nur an der Wand hängt. Sichtbarkeit allein reicht dafür nicht, erst die tägliche Nutzung macht den Unterschied. Zum Schluss kommt das Lernen als fünfte Funktion ins Spiel. Dabei geht es darum, die Annahmen hinter der Vision regelmäßig zu überprüfen. Neue Erkenntnisse aus Research, Nutzung oder Marktbeobachtung fließen ein, während der eigentliche Erinnerungsanker meist stabil bleibt. Bleibt diese Funktion aus, entsteht mit der Zeit eine Art Visionsschuld. Veraltete Annahmen und widersprüchliche Zielbilder passen dann längst nicht mehr zur Realität. Wie oft ein Team diesen Check braucht, hängt von der Lebensphase des Produkts ab. Junge Produkte mit vielen neuen Erkenntnissen reflektieren häufiger, etablierte Produkte reichen oft schon vierteljährliche Runden. Die fünf Funktionen von Produktvisionen bilden kein Phasenmodell, das man einmal durchläuft, sondern ein Modell in dem sie sich gegenseitig andauernd beeinflussen. Ein Team kann in einer Funktion stark und in einer anderen schwach sein. Genau dieser Blick lohnt sich als Reflexionsübung. Ist das Verdichten gut, das Klären aber schwach, klingt eine Vision oft überzeugend, obwohl sie zu wenig fundiert ist. Sind Anwenden und Lernen niedrig, entsteht schnell der bekannte Wandpostereffekt, schön anzusehen, aber ohne echten Nutzen.

Alexander Sprogis ist im Gespräch mit Tim In dieser Folge ist Alexander Sprogis bei Tim zu Gast. Gemeinsam sprechen die beiden über Produktentwicklung mit einem agentischen Team und über die Frameworks die man kennen sollte. Alex kommt ursprünglich aus der Softwareentwicklung und dem Produktmanagement. Früher gründete er mit Lilith Brockhaus die No-Code & Low-Code Ausbildung und KI-Beratung VisualMakers. Inzwischen baut er unter eigenem Namen seinen YouTube Kanal rund um AI Coding auf. Seine Leidenschaft gilt seit jeher dem Befähigen von Menschen. Heute geht es dabei vor allem um Coding Agents wie Claude Code. Wer einfach drauflos promptet, landet schnell im klassischen Vibe Coding. Viele Ergebnisse wirken gut, sind aber kaum reproduzierbar. Die KI trifft munter eigene Annahmen, ohne dich zu fragen. Alex vergleicht Coding Agents gern mit einem hastigen Junior Entwickler. Der liefert zwar schnell, neigt aber zum Overengineering. Auch Widerspruch legt so ein Agent nur selten ein. Dazu kommt ein Problem namens Context Rot. Je länger eine Session dauert, desto voller wird das Kontextfenster. Und desto öfter verliert die KI den roten Faden. Um dieses Chaos einzufangen, kann man vier Ebenen unterscheiden: Ganz unten steht das Sprachmodell (LLM) selbst, etwa Claude Opus oder Fable. Darüber liegt der Harness, also die Konfigurationsschicht, zum Beispiel Claude Code. Darüber wiederum sitzt das Framework als methodischer Rahmen für die eigentliche Arbeit. Innerhalb dieses Rahmens übernehmen einzelne Agenten oder Skills konkrete Rollen. Genau hier zeigt sich der Kern von Produktentwicklung mit einem agentischen Team. Ein gutes Framework bringt Struktur und wiederholbare Qualität in die tägliche Arbeit mit Coding Agents. Am ausführlichsten sprechen die beiden über die BMad Methode. BMad steht mittlerweile meist für "Breakthrough Method for Agile AI Driven Development" - manchmal aber auch für seinen Erfinder Brian Madison. Das Framework stellt ein komplettes agentisches Team aus neun Personas bereit. Die Business Analystin Mary erstellt mit dir zusammen ein Product Brief. Ein Produktmanager übersetzt das anschließend in ein PRD. Der Architekt Winston plant danach Technik und Stack. Am Ende entstehen daraus Epics und Storys mit klaren Akzeptanzkriterien. Es ist fast vergleichbar mit einem Team, das sich Dokumente zuwirft. Von echter gemeinsamer Arbeit an einem Inkrement (im Sinne von Scrum) bleibt allerdings wenig übrig. Ein sogenannter Party Mode bringt immerhin mehrere Agenten an einem Artefakt zusammen. Alex nutzt BMad selbst produktiv, sieht aber auch klare Grenzen. Für einzelne Personen entsteht schnell zu viel Dokumentation. Ein Project Brief kann schon mal mehrere Seiten lang werden. Ein Architekturdokument wird schnell zu einem kleinen Buch. Wer allein arbeitet, muss all das lesen und pflegen. Bei jeder Änderung fällt zusätzlich noch ein Review an. In kleinen Teams führt das schnell zu Overhead statt zu Tempo. Deshalb setzt Alex das Framework heute nur noch punktuell ein. Parallel schaut er sich längst andere Ansätze an. Als leichtere Alternative gibt es auch 'Get Shipped Done', früher bekannt als 'Get Shit Done'. Es läuft in einer kurzen Schleife aus fünf Phasen. Erst wird besprochen, dann geplant, dann umgesetzt, geprüft und ausgeliefert. Einzelne Unteragenten starten dabei mit einem leeren Kontextfenster. Sie melden am Ende nur ihr fertiges Ergebnis zurück. Ein Befehl namens Map Codebase schickt gleich sieben Unteragenten los. Die analysieren eine bestehende Codebasis aus verschiedenen Blickwinkeln. Das hilft besonders bei Legacy Projekten ohne gute Dokumentation. Superpowers verfolgen einen ähnlichen Ablauf, arbeiten aber testgetrieben. Erst entstehen die Tests, dann nur so viel Code wie nötig. So bremst das Framework Overengineering von vornherein aus. Neben BMad, Get Shipped Done und Superpowers fallen in der Folge noch weitere Namen. SpecKit von GitHub gehört dazu, ebenso Kiro von Amazon und AgentOS. Alex selbst hat sich aus mehreren Ansätzen ein eigenes System gebaut. Es orientiert sich stark an SpecKit und bleibt bewusst schlank. Ergänzt wird es um Skills für Spezifikation, Design, Umsetzung und Qualitätssicherung. Er nennt es AI Coding Starter Kit und stellt es als Open Source Projekt bereit. In Workshops mit Produkt und Engineering Teams kommt es regelmäßig zum Einsatz. Jedes Team passt es danach an die eigenen Abläufe an. Zum Abschluss rät Alex allen Produktmenschen, klein anzufangen. Ein privates Projekt reicht völlig als erster Schritt. Auch ein kleiner Anwendungsfall aus dem Alltag eignet sich gut dafür. So beginnt Produktentwicklung mit einem agentischen Team ganz ohne Risiko. Die Zeit des Abwartens ist eindeutig vorbei. Wer jetzt noch zuschaut, statt selbst mit Claude Code zu experimentieren, verpasst gerade viel. Ein Grund mehr, etwa ein privates Projekt zu schaffen um sich mit diesen Tools bekannt zu machen! Eine frühere Episode, die zu dieser Folge passt, ist "Wie No-Code Tools Produktteams helfen können (mit Lilith Brockhaus)" Folgende Quellen von Alexander Sprogis empfehlen wir euch: Kostenloses AI Coding Starter Kit BMAD Methode (Github) Einführung in Get Ship Done Einführung in Superpowers Claude Code: Kompletter Guide für deine erste Web-App (Video) Vom Einsteiger zum Pro: 5 Stufen von Claude Code (Video) AI Engineering Accelerator Hast du bereits Erfahrung gesammelt mit agentischer Produktentwicklung? Oder hast du noch nie damit gearbeitet und weißt nicht wie du anfangen sollst? Teilt eure Erfahrungen doch mit uns und der Community. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Tim & Oliver im Gespräch Worum es geht Backlog priorisiert, im Refinement erklärt, warum was wichtig ist – und trotzdem diskutiert das Team jede Entscheidung, oder einzelne Teammitglieder machen am Ende etwas ganz anderes als vereinbart. Egal ob mit Scrum, Kanban oder einer anderen Arbeitsweise: Dieses Gefühl kennen viele Product Owner. Tim und Oliver gehen der Frage nach, was in solchen Situationen wirklich passiert. Was "Folgen" als Product Owner eigentlich bedeutet Bevor es um Ursachen und Lösungen geht, steht eine grundsätzlichere Frage im Raum: Müssen Teammitglieder einem Product Owner überhaupt "folgen" – und was heißt das eigentlich? Ansagen machen, echte Zustimmung bekommen oder Entscheidungen verstehen und mittragen, auch ohne ihnen zuzustimmen, sind drei völlig unterschiedliche Dinge. Product Owner sind Führungskräfte, aber keine Vorgesetzten. Wer vorher Team- oder Projektleiter war und in die Product-Owner-Rolle gewechselt ist, fällt leicht in ein klassisches Ansage-Verständnis von Führung zurück. Echte Zustimmung und Mittragen lassen sich damit aber nicht erzeugen – die müssen sich Product Owner durch Vertrauen, Kompetenz und Empathie erst verdienen. Mögliche Ursachen, wenn das Team nicht folgt Tim und Oliver sammeln mehrere Gründe, warum ein Team einem Product Owner inhaltlich nicht folgt: Fehlendes Vertrauen auf der Beziehungsebene zwischen Product Owner und Team. Fehlendes Verständnis: Das Warum hinter einer Entscheidung wurde nicht ausreichend vermittelt – fehlende "Problemempathie" für das Nutzerproblem, das gelöst werden soll. Scheinbeteiligung: Feedback wird zwar eingeholt, hat aber erkennbar keinen Einfluss auf die Entscheidung, weil der Product Owner ohnehin allein entscheidet. Geschwindigkeits-Mismatch: Der Product Owner ist im eigenen Denken und in der Transformation schon weiter als das Team und überfordert es dadurch. Fehlendes gemeinsames Ziel: Ohne eine nachvollziehbare Kette von Vision über Strategie und Roadmap bis zum Sprint Goal (Decision Stack) wirkt die Priorisierung willkürlich. Zwischenmenschliche oder politische Konflikte: Manchmal steckt hinter dem Nicht-Folgen auch offene Verweigerung – etwa, wenn jemand die eigene frühere Entscheidungsmacht verloren hat oder agile Arbeitsweisen grundsätzlich ablehnt. Wichtig ist dabei die Unterscheidung: Folgt das gesamte Team nicht, liegt die Ursache eher beim Product Owner selbst. Verweigern sich einzelne Personen, kann das auch an ihnen liegen. Typische, aber wenig hilfreiche Reflexe Als Reaktion beobachten Tim und Oliver häufig: mehr Kontrolle, ein Rückfall in Command-and-Control-Muster, Resignation, das Abschieben von Verantwortung an andere, immer detailliertere Tickets oder zusätzliche Meetings. Ohne die eigentliche Ursache zu klären, ändern diese Reflexe am Grundproblem meist nichts. Was stattdessen hilft Stattdessen empfehlen Tim und Oliver: Gemeinsame Klarheit über das Warum herstellen – wer ist die Zielgruppe, welches Problem wird gelöst, woran erkennt man Erfolg. Mehr visualisieren statt nur Tickets schreiben – mit dem Stift denken macht Missverständnisse sichtbarer. Situativ führen und Entscheidungsstile bewusst an die jeweilige Situation anpassen, statt immer gleich zu entscheiden oder zu delegieren. Bei sich selbst anfangen: die eigene Kommunikation und ihre Wirkung reflektieren, statt Feedback vorschnell als persönlichen Angriff oder reines Teamversagen abzutun. Sich Hilfe holen – durch einen Scrum Master oder Agile Coach, einen Sparringspartner im Team oder einen anderen Product Owner. Aus Sicht von Tim und Oliver in Organisationen werden Entwickler:innen viel zu selten in agilen Arbeitsweisen und modernem Produktmanagement geschult, dabei trägt im Idealfall das ganze Team Produktverantwortung. Fazit Wenn ein Team dem Product Owner nicht folgt, lohnt sich zuerst der Blick auf die eigene Kommunikation und das gemeinsame Zielverständnis, bevor mit mehr Kontrolle reagiert wird. Bei einzelnen, dauerhaft verweigernden Teammitgliedern kann aber auch das offen angesprochen werden – bis hin zu klaren Konsequenzen. Folgende Episoden könnten dich auch interessieren [Folge mit Arne Kittler zu Klarheit und Rollenklarheit]](https://produktwerker.de/klarheit-fuer-produktmenschen/)) [Folge mit Bernd Joussen zu Konflikten zwischen Product Ownern und Developern]](https://produktwerker.de/welchen-einfluss-auf-die-retrospektive-hat-ein-product-owner/)) [Folge mit Sohrab Salimi: "Product Owner als Agile Leader"]](https://produktwerker.de/product-owner-als-agile-leader/)) [Folge "Product Owner ohne Scrum Master"]](https://produktwerker.de/product-owner-ohne-scrum-master/)) [Folge mit Frank Wolfes zu Decision Poker]](https://produktwerker.de/entscheidungen-treffen-decision-poker/))

Tim & Oliver im Gespräch **Worum es geht ** Wer Verantwortung für den Wert eines Produkts trägt, muss ständig entscheiden, welche Arbeit zuerst umgesetzt wird. Genau an dieser Stelle beginnt oft die Suche nach einer Methode, die Diskussionen beendet und Entscheidungen nachvollziehbar macht. Frameworks wie ICE, RICE, Kano oder WSJF schaffen eine gemeinsame Struktur für Bewertungen. Sie helfen dabei, Argumente zu sortieren und Annahmen sichtbar zu machen. Trotzdem entsteht daraus noch keine objektive Wahrheit. Wer objektiv priorisieren möchte, bewegt sich immer in einem Umfeld, das von Unsicherheit, Abhängigkeiten und unterschiedlichen Interessen geprägt ist. Viele Product Owner investieren viel Zeit in Bewertungsmodelle, Gewichtungen und Tabellen. Dahinter steckt die Hoffnung, dass sich Priorisierung irgendwann berechnen lässt. Die Erfahrung zeigt jedoch etwas anderes. Schon kleine Abhängigkeiten zwischen Backlog-Einträgen verändern die Reihenfolge. Hinzu kommen Faktoren, die sich kaum in Zahlen ausdrücken lassen: Strategische Ziele ändern sich, neue Erkenntnisse entstehen, Stakeholder verfolgen unterschiedliche Interessen. Manche Entscheidungen werden auch durch Budget, Verantwortung oder organisatorische Zwänge beeinflusst. Wer objektiv priorisieren will, sollte deshalb akzeptieren, dass keine Formel alle Einflussfaktoren erfassen kann. Rechenmodelle unterstützen das Denken – sie ersetzen keine Entscheidung. ### Warum Diskussionen dazugehören Gerade deshalb gehört die Auseinandersetzung mit unterschiedlichen Sichtweisen zur Arbeit eines Product Owners. Wenn eine Priorisierung hinterfragt wird, ist das nicht automatisch ein Zeichen für eine schlechte Methode. Häufig fehlen Informationen, Perspektiven oder Hintergründe, die erst im Gespräch sichtbar werden. Der Versuch, jede Diskussion durch ein Bewertungsmodell zu vermeiden, führt selten zu besseren Ergebnissen. Viel hilfreicher ist es, die unterschiedlichen Beweggründe zu verstehen und gemeinsam abzuwägen, welche Reihenfolge den größten Beitrag zum Produkterfolg leistet. Objektiv priorisieren bedeutet deshalb nicht, Diskussionen abzuschaffen. Es bedeutet, Entscheidungen nachvollziehbar zu machen und sie auf einer möglichst breiten Informationsbasis zu treffen. ### Fazit Erfahrung, Problemverständnis und ein gutes Gespür für Kunden spielen dabei ebenso eine Rolle wie Daten und Kennzahlen. Diese Faktoren lassen sich nicht vollständig quantifizieren und bleiben dennoch wertvoll. Produktentwicklung findet in einem komplexen Umfeld statt, in dem sich Rahmenbedingungen ständig verändern. Genau deshalb braucht es Menschen, die Verantwortung übernehmen, unterschiedliche Perspektiven zusammenführen und Prioritäten immer wieder neu bewerten. Wer objektiv priorisieren möchte, erreicht sein Ziel nicht mit der perfekten Formel, sondern mit Transparenz, gemeinsamer Reflexion und der Bereitschaft, Entscheidungen immer wieder anhand neuer Erkenntnisse zu überprüfen.

Jan Werner im Gespräch mit Tim Jan Werner spricht in dieser Folge mit Tim darüber, wie AI im Produktmanagement seinen Arbeitsalltag als Lead Product Manager von Instaffo massiv verändert hat und dass der größte Gewinn nicht in spektakulären Demos, sondern in vielen kleinen Verbesserungen liegt. Seine Erfahrungen stammen aus der täglichen Arbeit in der Praxis und zeigen, wie sich der Einsatz von AI Schritt für Schritt entwickelt. Der Einstieg in das Thema begann wie so oft mit einfachen Aufgaben wie Produkttexten und wuchs mit jeder neuen Erfahrung. Dadurch entstand nach und nach ein Arbeitsstil, bei dem AI selbstverständlich zum Werkzeugkasten in Jans Umfeld gehört, ohne dass die AI dabei Verantwortung für Entscheidungen oder Produktstrategie übernimmt. AI im Produktmanagement entfaltet ihren Wert dort, wo viel Zeit in wiederkehrende Denk- und Schreibarbeit fließt. Wer Anforderungen vorbereitet, Produkttexte formuliert oder umfangreiche Informationen zusammenführt, kennt den mental Load vor einem Refinement oder einer wichtigen Abstimmung. Genau an diesen Stellen schafft AI Freiräume. Statt Stunden in die Formulierung von Tickets oder Dokumenten zu investieren, bleibt mehr Zeit für Recherche, Bewertung von Erkenntnissen und den Austausch mit dem Team. Der Fokus verschiebt sich auf die Qualität der Entscheidungen und nicht auf die reine Produktion von Texten. Mit wachsender Erfahrung verändert sich auch die Art der Zusammenarbeit mit AI. Aus einzelnen Prompts entstehen persönliche Werkzeuge, die den eigenen Arbeitskontext kennen und auf bestehendes Wissen zugreifen. Repositories, wiederverwendbare Skills und agentische Arbeitsweisen sorgen dafür, dass Ergebnisse nicht jedes Mal neu aufgebaut werden müssen. Dadurch wächst das Vertrauen in den Einsatz und gleichzeitig steigen die Erwartungen an die eigene Arbeitsweise. AI im Produktmanagement entwickelt sich damit von einer Unterstützung für einzelne Aufgaben zu einem festen Bestandteil des gesamten Produktprozesses. Diese Entwicklung verlangt allerdings mehr als die Auswahl eines guten Modells. Wer AI sinnvoll einsetzen möchte, braucht Klarheit über den eigenen Arbeitsablauf und über die Qualität des vorhandenen Wissens. Schlechte Dokumentation oder fehlender Kontext lassen sich nicht durch bessere Prompts ausgleichen. Erst wenn Produktwissen sauber strukturiert vorliegt, kann AI darauf aufbauen und wirklich nützliche Ergebnisse liefern. Genau deshalb verändert sich mit dem Einsatz von AI im Produktmanagement nicht nur die tägliche Arbeit, sondern auch der Blick auf Dokumentation, Zusammenarbeit und kontinuierliches Lernen. Interview Guide Skill Jan hat uns im Nachgang auch noch seinen Interview Guise Skill für euch zur Nutzung oder Nachahmung bereitgestellt. Es ist ein Workflow, der Produktmanager durch den gesamten Lebenszyklus von Nutzerbefragungen begleitet: Vorbereitung, Analyse und Integration. Entwickelt für Claude Code. Funktioniert mit jedem Produkt, jedem Nutzertyp und jeder Teamzusammensetzung: https://github.com/jnwrnr/user-interview-guide-skill Umfrage: “Hands-on mit AI” – oder nur KI-Theater? Jan Werner checkt mit einer Survey, wie PMs und PO in der täglichen Arbeit wirklich mit AI arbeiten. Das ganze dauert nur ca. 10 Minuten und die Ergebnisse gibt’s exklusiv für Teilnehmende an der Umfrage. Wenn Du als Produktmanager:in oder Product Owner:in arbeitest, mach also bitte noch mit: Hands-on Product Survey 2026 Folgende Episoden wurden von Tim im Laufe des Gesprächs erwähnt bzw. empfohlen: Was kann AI im Produktmanagement heute schon wirklich? Nutze Story Mapping, um mit Stakeholdern über Outcome zu sprechen Seine Stakeholder kennen und richtig analysieren Wer weitere Fragen an Jan Werner hat oder mit ihm in Kontakt treten will, erreicht ihn am besten über sein LinkedIn-Profil. Wieviel arbeitest du bereits AI-unterstützt im Produktmanagement-Kontext? Wobei unterstützt dich die KI bereits sinnvoll? Oder hast du noch Zweifel an der ganzen Thematik? Teilt eure Erfahrungen doch mit uns und der Community. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Paul Wall im Gespräch mit Dominique Paul Wall spricht gemeinsam mit Dominique über seinen Weg von der User Experience ins Produktmanagement und darüber, warum der Wechsel von UX zu PM für ihn der nächste konsequente Schritt war. Viele Menschen mit einem Hintergrund in Design oder User Experience erleben, dass sie Nutzerinnen und Nutzer zwar sehr gut verstehen, auf wichtige Produktentscheidungen aber nur begrenzten Einfluss haben. Genau das hat Paul während seiner persönlichen Entwicklung gespürt. Er sucht nach mehr Verantwortung, möchte früher an Entscheidungen beteiligt sein und findet im Produktmanagement die Möglichkeit, seine Erfahrungen wirksamer einzubringen. Damit wird UX zu PM für ihn weit mehr als ein Rollenwechsel. Es verändert die eigene Perspektive auf Produkte und die Zusammenarbeit mit anderen Bereichen. Der Weg von UX zu PM beginnt bei Paul nicht mit einer Bewerbung, sondern mit der Erkenntnis, dass Veränderungen innerhalb seines damaligen Unternehmens kaum möglich sind. Er versucht zunächst, das Verständnis für User Experience auf unterschiedlichen Ebenen zu stärken. Als dieser Ansatz an Grenzen stößt, sucht er nach einer fundierten Weiterbildung statt nach einem kurzen Zertifikatskurs. Die Entscheidung für ein mehrmonatiges Vollzeitprogramm gibt ihm die Gelegenheit, Methoden des Produktmanagements intensiv kennenzulernen und direkt an einem eigenen Projekt anzuwenden. Gleichzeitig baut er auf Fähigkeiten auf, die er bereits aus der User Experience mitbringt. Empathie, das Verständnis für unterschiedliche Menschen und die Gewohnheit, Ideen früh sichtbar zu machen, helfen ihm dabei, auch in der neuen Rolle schnell Wirkung zu entfalten. Besonders spannend war für ihn, wie sich die Arbeitsweise verändert hat. Statt lange über Konzepte zu diskutieren, entstehen früh greifbare Entwürfe und Prototypen, die Gespräche mit Stakeholdern erleichtern. Gleichzeitig wächst das Bewusstsein dafür, dass erfolgreiche Produktarbeit mehr verlangt als gute Lösungen für Nutzerinnen und Nutzer. Wer den Schritt von UX zu PM geht, muss lernen, die Sprache von Geschäftsführung, Vertrieb und weiteren Beteiligten zu sprechen. Paul beschreibt, wie schon kleine Veränderungen in der Kommunikation die Akzeptanz für Ideen erhöhen können. Damit rückt nicht die Methode in den Vordergrund, sondern die Fähigkeit, unterschiedliche Perspektiven miteinander zu verbinden und gemeinsame Entscheidungen zu ermöglichen. Pauls Erfahrung zeigt, dass der Wechsel von UX zu PM weder zufällig noch einfach verläuft. Er verlangt die Bereitschaft, vertraute Denkmuster zu hinterfragen, neues Handwerkszeug zu lernen und Verantwortung für das gesamte Produkt zu übernehmen. Gleichzeitig wird deutlich, dass viele Kompetenzen aus der User Experience ihren Wert behalten und sogar an Bedeutung gewinnen, wenn sie mit Produktmanagement verbunden werden. Wer heute über den eigenen nächsten Karriereschritt nachdenkt, findet darin viele praktische Anknüpfungspunkte und erkennt, wie sich vorhandene Stärken in einer neuen Rolle gezielt weiterentwickeln lassen. Was Paul in dieser Folge erwähnt: Event: Product Lean Coffee (https://www.linkedin.com/groups/12524562/)) Empfehlung: Simonetta Batteiger (https://www.linkedin.com/in/simonettabatteiger/)) Folge: JTBD (https://produktwerker.de/podcast-episode/mit-jobs-to-be-done-zu-mehr-kundenverstaendnis/)) Folge: Assumption Mapping (https://produktwerker.de/podcast-episode/assumption-mapping/)) Event: UX Festival (https://www.ux-festival.org/)) Fortbildung: Digitale Leute School (https://school.digitale-leute.de/)) Buch: 50 Arten Nein zu sagen (https://dpunkt.de/produkt/50-arten-nein-zu-sagen/))

Dominique & Tim im Gespräch In dieser Folge sprechen Tim und Dominique über den sogenannten "Six Pager" als besondere Form des Written Narrative. Der Six Pager stammt aus dem Umfeld von Amazon und steht für weit mehr als nur ein Dokument mit sechs Seiten Fließtext. Er schafft einen Rahmen, in dem Gedanken vollständig entwickelt werden, bevor andere Menschen darüber diskutieren und entscheiden. Genau darin liegt seine Stärke. Wer eine Idee schriftlich nachvollziehbar erklärt, beschreibt nicht nur die gewünschte Lösung, sondern setzt sich intensiv mit dem Problem, dem Kontext, den Annahmen, Gegenargumenten möglichen Alternativen und den Risiken auseinander. Das führt häufig zu einer deutlich besseren Grundlage für Entscheidungen als eine Präsentation mit wenigen Stichpunkten ("Death by PowerPoint"). Ein Six Pager verändert gleichzeitig die Art, wie Meetings ablaufen. Statt Folien zu präsentieren und dabei auf Vorwissen zu hoffen, lesen alle Beteiligten den Text zunächst gemeinsam. Erst danach beginnt die Diskussion. Dadurch entsteht ein gemeinsames Verständnis, bevor Meinungen aufeinander treffen. Niemand muss vermuten, ob einzelne Personen die Unterlagen vorher gelesen haben oder wichtige Informationen fehlen. Gleichzeitig zwingt das Schreiben im Vorfeld dazu, die eigenen Gedanken zu ordnen. Wer eine Idee nicht klar aufschreiben kann, hat sie oft selbst noch nicht vollständig durchdacht. Genau deshalb eignet sich ein Six Pager besonders für strategische Entscheidungen, neue Produktinitiativen oder wichtige Investitionen. Der Six Pager ist jedoch kein Werkzeug für jede Situation. Niemand sollte alltägliche Abstimmungen oder kleine operative Entscheidungen auf diese Weise dokumentieren. Der Aufwand lohnt sich dort, wo Tragweite und Unsicherheit zusammenkommen und unterschiedliche Sichtweisen berücksichtigt werden müssen. Gerade Product Owner, Produktmanager und Führungskräfte profitieren davon, weil sie Entscheidungen regelmäßig begründen und verschiedene Interessen zusammenbringen. Ein sauber formuliertes Written Narrative macht Annahmen sichtbar, legt Zielkonflikte offen und schafft eine gemeinsame Grundlage für konstruktive Diskussionen. Das verbessert nicht nur die Qualität von Entscheidungen, sondern auch die Zusammenarbeit innerhalb einer Produktorganisation. Wer den Six Pager zum ersten Mal ausprobiert, merkt schnell, dass Schreiben vor allem ein Denkwerkzeug ist. Gute Texte entstehen nicht nebenbei. Sie fordern Klarheit und machen Lücken im eigenen Verständnis sichtbar. Genau deshalb ersetzt ein Six Pager keine Präsentation, sondern verfolgt einen anderen Zweck. Statt Informationen möglichst kompakt auf Folien zu verdichten, entwickelt er einen nachvollziehbaren Gedankengang, der von der Ausgangssituation bis zur Empfehlung führt. So entsteht eine Entscheidungsvorlage, die Diskussionen auf ein deutlich höheres Niveau hebt und Produktteams dabei unterstützt, bewusstere und tragfähigere Entscheidungen zu treffen. Es gibt jede Menge gut Quellen, um noch tiefer in das Thema einzusteigen: Marty Cagan (svpg): Coaching Tools – The Narrative: https://www.svpg.com/coaching-tools-the-narrative/ Using 6 Page and 2 Page Documents To Make Organizational Decisions: https://inowland.medium.com/using-6-page-and-2-page-documents-to-make-organizational-decisions-3216badde909 The Beauty of Amazon's 6-Pager: https://www.linkedin.com/pulse/beauty-amazons-6-pager-brad-porter?utm_source=share&utm_medium=member_ios&utm_campaign=share_via How Amazon Innovates: https://www.digitaltonto.com/2018/how-amazon-innovates/ Working Backwards: https://medium.com/keqius-management-notes/working-backwards-e3a8ea5a99ab Startups: How to Use Amazon’s Narrative Process to Set Goals and Think Clearly: https://aws.amazon.com/blogs/startups/startup-advice-how-to-write-a-narrative/ The Anatomy of an Amazon 6-pager: https://writingcooperative.com/the-anatomy-of-an-amazon-6-pager-fc79f31a41c9 Leadership Principles bei amazon: https://www.amazon.jobs/content/en/our-workplace/leadership-principles How to write an Amazon-style narrative memo: https://newsletter.seomba.com/p/how-to-write-an-amazon-style-narrative The Power of Amazon's Written Narratives: https://www.sachinrekhi.com/colin-bryar-working-backwards Working Backwards: Insights, Stories, and Secrets from Inside Amazon https://amzn.eu/d/dah5obV Das Amazon-Geheimnis – Strategien des erfolgreichsten Konzerns der Welt: https://amzn.eu/d/hRCrIwG What is a Narrative? (Video): https://youtu.be/lw9EO04MpJU Working backwards: Amazon’s approach to innovation (Video): https://youtu.be/aFdpBqmDpzM Im Gespräch wurde auf diese älteren Episoden hingewiesen: Assumption Mapping Wie die Produktvision hilft, Product Ownern eine Richtung zu geben Eine Produktstrategie ohne Canvas erarbeiten (mit Tim Herbig) Habt ihr den Six Pager oder grundsätzlich ein Written Narrative schon einmal genutzt bzw. ausprobiert? Habt ihr Meetings erlebt in denen ein Six Pager wahrscheinlich mehr geholfen hätte als eine PowerPoint Präsentation?Teilt eure Erfahrungen doch mit uns und der Community. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Tim & Dominique im Gespräch Tim und Dominique sprechen in dieser Folge darüber, wie sich Produkte erfolgreich in Organisationen einführen lassen und warum ein abgeschlossener Rollout dafür noch lange nicht ausreicht. Viele Unternehmen investieren viel Zeit und Geld in neue Software, Plattformen oder interne Werkzeuge. Die technische Einführung gelingt häufig nach Plan. Trotzdem greifen Mitarbeitende weiter zu ihren gewohnten Lösungen oder entwickeln Umgehungswege. Das eigentliche Problem liegt oft nicht im Produkt selbst, sondern darin, wie Menschen Veränderungen erleben und in ihren Arbeitsalltag integrieren. Wer Produkte erfolgreich in Organisationen einführen möchte, muss verstehen, dass jede neue Lösung bestehende Routinen verändert. Viele Arbeitsabläufe funktionieren über Jahre hinweg zuverlässig und geben Sicherheit. Neue Werkzeuge verlangen dagegen neue Abläufe, neue Entscheidungen und manchmal auch neue Verantwortlichkeiten. Selbst wenn eine Anwendung objektiv besser ist, entsteht dadurch zunächst Unsicherheit. Schulungen vermitteln Funktionen, sie ersetzen aber keine neuen Gewohnheiten. Eine Rundmail oder eine Ankündigung im Intranet schafft ebenfalls noch keine Akzeptanz. Erst wenn Menschen erkennen, welchen konkreten Nutzen eine Veränderung für ihre tägliche Arbeit bringt, wächst die Bereitschaft, neue Arbeitsweisen dauerhaft anzunehmen. Besonders sichtbar wird dieses Muster derzeit beim Einsatz von Anwendungen rund um Künstliche Intelligenz. Viele Organisationen investieren in moderne Werkzeuge und erwarten schnelle Verbesserungen. Gleichzeitig probieren Mitarbeitende häufig eigenständig andere Lösungen aus oder bleiben bei vertrauten Arbeitsweisen. Dieses Spannungsfeld zeigt, dass erfolgreiche Einführung weit mehr bedeutet als Berechtigungen zu vergeben oder Lizenzen bereitzustellen. Produkte erfolgreich in Organisationen einführen heißt auch, bestehende Prozesse, informelle Zusammenarbeit und gewachsene Strukturen mitzudenken. Veränderungen betreffen selten nur die Oberfläche einer Software. Sie beeinflussen Zusammenarbeit, Entscheidungswege und das persönliche Sicherheitsgefühl der Menschen, die täglich mit dem Produkt arbeiten. Nachhaltige Nutzung entsteht deshalb durch kontinuierliche Begleitung statt durch einen einzelnen Einführungstermin. Produktteams und Verantwortliche sollten früh zuhören, typische Hürden erkennen und gemeinsam mit den späteren Nutzerinnen und Nutzern passende Lösungen entwickeln. Feedback aus dem Arbeitsalltag hilft dabei, Hindernisse abzubauen und Vertrauen aufzubauen. Wer Produkte erfolgreich in Organisationen einführen möchte, betrachtet den Rollout nicht als Abschluss eines Projekts, sondern als Beginn einer gemeinsamen Veränderung. Erst wenn Menschen den Mehrwert erleben und neue Routinen entwickeln, kann ein Produkt seine Wirkung in der Organisation vollständig entfalten. In dieser Episode wurde auf folgende ältere Folgen hingewiesen: Product Principles (Produktprinzipien) Mit "Jobs to Be Done"-Interviews zum besseren Kundenverständnis (JTBD) Hast du auch erlebt wie ein Unternehmen neue Produkte eingeführt hat und es besonders gut oder besonders schlecht gelaufen ist? Weshalb hat es in diesen Fällen (nicht) funktioniert deiner Meinung nach? Teilt eure Geschichten und Erfahrungen doch mit uns und der Community. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Tim & Oliver im Gespräch Oliver und Tim sprechen in dieser Folge darüber, warum viele Product Owner auf bessere Rahmenbedingungen warten und sich damit oft selbst ausbremsen. Im Alltag fehlt die Produktvision, Prioritäten bleiben unklar oder wichtige Entscheidungen kommen nicht voran. Solche Situationen kennen viele. Der Reflex ist häufig, auf Führungskräfte, Stakeholder oder andere Teams zu zeigen und von diesen eine Lösung zu erwarten. Genau dort beginnt jedoch ein Muster, das wenig verändert. Wer dauerhaft darauf wartet, dass andere den ersten Schritt machen, gibt einen Teil seines eigenen Gestaltungsspielraums aus der Hand. Warte nicht darauf, dass das Umfeld perfekt wird, bevor du Verantwortung übernimmst. Besonders spannend ist die Frage nach dem eigenen Antrieb. Viele Produktmenschen können sehr präzise beschreiben, was in ihrer Organisation nicht funktioniert. Deutlich schwieriger wird es oft bei der Antwort auf die Frage, warum sie ihr Produkt eigentlich voranbringen wollen. Wer für sich keine Richtung erkennt, landet schnell im Beschwerdemodus. Dann dreht sich die Aufmerksamkeit vor allem um Hindernisse. Aber warte nicht darauf, dass jemand anderes Sinn und Orientierung liefert. Beschäftige dich mit dem Wert deines Produkts, mit den Menschen, die es nutzen, und mit dem Beitrag, den du selbst leisten möchtest. Daraus entsteht auch Energie für Veränderung. Fehlende Strategien oder unklare Ziele sind häufige Auslöser für Frust. Viele Product Owner wünschen sich eine klare Unternehmensstrategie, bevor sie Entscheidungen treffen oder Diskussionen glauben weitertreiben zu können. Dieser Wunsch ist nachvollziehbar. Trotzdem hilft Abwarten selten weiter. Also warte nicht, bis jede Antwort von oben kommt. Suche das Gespräch, stelle Fragen und mache sichtbar, welche Entscheidungen ohne Orientierung schwerfallen bzw. auf Basis welcher Hypothesen du vorangehen wirst. Wer aktiv Zusammenhänge aufzeigt und konkrete Vorschläge einbringt, erhöht die Chance auf Klarheit deutlich stärker als jemand, der lediglich auf Missstände hinweist. Ähnlich verhält es sich bei der Zusammenarbeit mit Stakeholdern. Wenn Anforderungen ungefiltert ins Team gelangen oder jede Aufgabe höchste Priorität erhält, entsteht schnell das Gefühl von Kontrollverlust. Viele Product Owner sehen das Problem sehr klar, bleiben aber in der Rolle der Beobachtenden. Warte nicht darauf, dass andere plötzlich anders arbeiten. Schaffe Transparenz über Auswirkungen, führe Priorisierungsdiskussionen und suche Verbündete. Einfluss entsteht selten durch die formale Rolle allein. Er wächst durch Initiative, durch Kommunikation und durch den Mut, schwierige Gespräche zu führen. Produktverantwortung bedeutet deshalb mehr als Backlog Pflege und Sprint Planung. Sie beginnt dort, wo Menschen ihr Umfeld aktiv mitgestalten. Niemand kann alle organisatorischen Probleme allein lösen. Darum geht es auch nicht. Entscheidend ist die Haltung, mit der man auf Herausforderungen blickt. Warte nicht auf die perfekte Organisation, die ideale Strategie oder die nächste Entscheidung von oben. Nutze den Handlungsspielraum, den du heute hast. Oft ist er größer, als es auf den ersten Blick erscheint. Im Gespräch wird von Tim und Oliver auf folgende ältere Episoden verwiesen: Umgang mit Produktrisiken Als Product Owner dein Zeitmanagement in den Griff bekommen Trotz Hierarchie durchsetzungsstark als Product Owner agieren Wo wartest du aktuell noch darauf, dass andere etwas verändern? Vielleicht fehlt eine klare Richtung. Vielleicht blockieren Priorisierungskonflikte oder schwierige Abstimmungen mit Stakeholdern den Fortschritt. Oft gibt es mehr Handlungsspielraum, als auf den ersten Blick sichtbar wird. Vielleicht hat diese Folge dir auch bereits geholfen Dinge in die eigene Hand zu nehmen. Teilt eure Geschichten und Erfahrungen doch mit uns und der Community. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns Produktwerkern auf LinkedIn -> https://bit.ly/3gWanpT Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Dominique & Oliver im Gespräch Darum geht es in dieser Episode Im Alltag von Product Ownern ziehen viele Erwartungen gleichzeitig an einem: Stakeholder wollen schnelle Antworten, das Team braucht Orientierung und das Backlog wird selten kürzer. Oliver und Dominique sprechen in dieser Folge darüber, wie Product Owner in dieser Verantwortung fokussiert und handlungsfähig bleiben können, ohne sich dauerhaft treiben zu lassen. Dabei geht es nicht darum, Stress einfach wegzuatmen oder Verantwortung abzugeben. Vielmehr schauen die beiden darauf, welche Routinen, Fragen und Perspektivwechsel helfen, mehr Klarheit in den eigenen Arbeitsalltag zu bringen. Dazu gehören Morgenrituale, Tages- und Wochenfokus, bewusste Pausen, Spaziergänge, Meditation und ein klarerer Umgang mit Dringlichkeit. In dieser Folge sprechen Oliver und Dominique darüber warum Product-Owner-Verantwortung schnell stressig werden kann wie ein klarer Tagesfokus entlastet warum die wichtigste Aufgabe möglichst früh am Tag ihren Platz braucht wie Aufgabenlisten, Bullet Journal oder Tools wie Trello und Sunsama helfen können weshalb Product Owner nicht alles selbst lösen müssen wie ein volles Product Backlog entspannter betrachtet werden kann welche Fragen bei äußerem Druck helfen warum „nicht jetzt“ oft wirksamer ist als ein hartes Nein wie Austausch, Coaching oder Mentoring mentale Stärke unterstützen können Zentrale Gedanken aus der Folge Stress entsteht häufig dort, wo Product Owner jede Dringlichkeit ungefiltert übernehmen. Deshalb hilft es, kurz innezuhalten und zu klären: Warum ist das jetzt dringend? Was passiert, wenn es heute nicht passiert? Welche andere Arbeit bleibt dafür liegen? Diese Fragen machen Entscheidungen bewusster und zeigen, dass jede Priorisierung einen Trade-off hat. Ein weiterer wichtiger Punkt ist der Umgang mit Verantwortung. Product Owner müssen nicht alles selbst tun, nur weil sie Verantwortung für den Produkterfolg tragen. Oft entsteht Entlastung genau dann, wenn Aufgaben bewusst an Menschen gegeben werden, die dafür näher dran oder besser geeignet sind. Erwähnte Praktiken und Impulse Morgenritual bewusst gestalten Tages- und Wochenfokus festlegen wichtigste Aufgabe zuerst angehen Aufgaben aus dem Kopf aufschreiben Pausen, Spaziergänge oder Meditation nutzen Dringlichkeit durch Fragen klären Unterstützung durch Austausch, Coaching oder Mentoring suchen Passende ältere Folgen Folge 7: Sei dein eigenes Produkt! – Weiterentwicklung für Product Owner Folge 108: Nein sagen als Product Owner Folge 111: Ownership verpflichtet Folge 126: Woran scheitern Product Owner? Folge 137: Welche Social Skills brauchen Product Owner? Links Produktwerker Website: https://produktwerker.de Podcast-Übersicht: https://produktwerker.de/podcast/

Dominique & Oliver im Gespräch Dominique und Oliver sprechen in dieser Folge darüber, warum die Wahl des richtigen Zielmarkts weit mehr ist als eine Marketingentscheidung. Wer Verantwortung für ein Produkt trägt, trifft jeden Tag Entscheidungen, die den weiteren Handlungsspielraum einschränken oder erweitern. Genau deshalb beeinflusst der Zielmarkt die Produktentwicklung von Anfang an. Er bestimmt, welche Probleme relevant sind, welche Bedürfnisse zählen und welche Rahmenbedingungen bei der Gestaltung eines Produkts berücksichtigt werden müssen. Für Product Owner:innen und Produktmanager:innen entsteht daraus eine wichtige Frage: Für wen entwickeln wir eigentlich und in welchem Markt soll unser Produkt erfolgreich sein? Ein Zielmarkt besteht aus deutlich mehr als einer Nutzergruppe. Geografische Unterschiede spielen ebenso eine Rolle wie rechtliche Vorgaben, kulturelle Erwartungen oder technologische Rahmenbedingungen. Ein Produkt kann in einem Markt hervorragend funktionieren und in einem anderen kaum Resonanz erzeugen. Manche Funktionen werden in einem Land erwartet, während sie anderswo keine Bedeutung haben. Wer diese Unterschiede ignoriert, riskiert hohe Investitionen in Lösungen, die am tatsächlichen Bedarf vorbeigehen. Der Zielmarkt setzt deshalb wichtige Leitplanken für Produktstrategie, Produktgestaltung und die Auswahl möglicher Lösungsansätze. Häufig entsteht der Wunsch, möglichst viele Kundengruppen gleichzeitig anzusprechen. In der Praxis führt das oft zu Produkten, die für niemanden wirklich überzeugend sind. Ein klar definierter Zielmarkt hilft dabei, Ressourcen gezielt einzusetzen und Prioritäten bewusster zu setzen. Statt jede denkbare Anforderung zu berücksichtigen, entsteht ein besseres Verständnis dafür, welche Probleme besonders relevant sind und wo der größte Nutzen geschaffen werden kann. Diese Fokussierung erleichtert viele Entscheidungen im Produktalltag und schafft Orientierung für Teams und Stakeholder. Die Suche nach dem passenden Zielmarkt beginnt selten mit vollständiger Sicherheit. Meist stehen zunächst Annahmen im Raum. Genau deshalb ist frühes Lernen so wichtig. Kundeninterviews, Beobachtungen im Nutzungskontext und direkte Gespräche mit potenziellen Kundinnen und Kunden helfen dabei, Marktsegmente besser zu verstehen. Dabei geht es nicht darum, Zustimmung für eine Idee einzusammeln. Entscheidend ist, die eigenen Hypothesen kritisch zu prüfen und herauszufinden, ob ein relevantes Problem tatsächlich existiert und ob die gewählte Zielgruppe bereit ist, sich damit auseinanderzusetzen. Auch der Product Market Fit entsteht nicht am Reißbrett. Ob ein Zielmarkt wirklich zum Produkt passt, zeigt sich oft erst nach den ersten Schritten im Markt. Die gewonnenen Erkenntnisse können Anpassungen am Produkt erforderlich machen. Manchmal zeigt sich sogar, dass ein anderer Zielmarkt deutlich besser geeignet ist. Erfolgreiche Produktentwicklung bedeutet deshalb, Markt und Produkt gemeinsam weiterzuentwickeln. Wer den Zielmarkt als lernbare Annahme versteht und regelmäßig hinterfragt, schafft bessere Voraussetzungen für nachhaltigen Produkterfolg. Im Kontext dieser Folge empfehlen wir euch insbesondere folgenden Folgen: User Feedback mit Kundeninterviews einholen (https://produktwerker.de/user-feedback-mit-kundeninterviews/)) Warum Personas für Product Owner wertvoll sind (https://produktwerker.de/warum-personas-fuer-product-owner-wertvoll-sind/)) Das Problem mit dem Minimal Viable Product (https://produktwerker.de/das-problem-mit-dem-minimal-viable-product/)) The Decision Stack (https://produktwerker.de/the-decision-stack/))

Aurelia Weimer im Gespräch mit Dominique In dieser Folge spricht Dominique mit Aurelia Weimer über ihre ersten 100 Tage als Product Ownerin. Im Mittelpunkt steht eine Einstiegsphase, die vor allem aus Lernen, Orientierung und vielen neuen Herausforderungen besteht, denn Product Ownership beginnt in der Praxis nicht immer mit einem gepflegten Backlog, klaren Entscheidungswegen oder einer abgestimmten Produktstrategie. Häufig stehen zunächst grundlegende Fragen im Vordergrund: Wie arbeiten die Menschen zusammen? Wer trifft welche Entscheidungen? Welche Erwartungen gibt es an das Produkt? Welche Strukturen helfen bereits und welche stehen eher im Weg? Aurelia berichtet, warum es am Anfang wichtig ist, nicht vorschnell Lösungen zu präsentieren, sondern zunächst Kontext aufzubauen. Dazu gehören fachliches Wissen über die Domäne, ein Verständnis für bestehende Routinen und ein genauer Blick auf die beteiligten Menschen und ihre Erwartungen. Ein weiterer Schwerpunkt der Folge ist die Zusammenarbeit mit dem Entwicklungsteam. Gemeinsame Workshops, offene Diskussionen und die bewusste Auseinandersetzung mit der eigenen Arbeitsweise werden als wichtige Elemente beschrieben, um Schritt für Schritt zu einem passenden Vorgehen zu finden. Dabei geht es weniger darum, Scrum-Elemente möglichst lehrbuchnah umzusetzen, sondern darum, herauszufinden, was dem Team in der konkreten Situation wirklich hilft. Die Folge zeigt außerdem, dass die ersten 100 Tage auch eine Phase persönlicher Entwicklung sind. Neues Domänenwissen, Unsicherheit und Verantwortung gehören ebenso dazu wie Fragen stellen, Unterstützung annehmen und den eigenen Wissensstand realistisch einordnen. Moderne Werkzeuge können den Einstieg erleichtern, etwa beim Erschließen fachlicher Themen oder beim Strukturieren von Informationen. Der Kern wirksamer Product Ownership bleibt jedoch die Arbeit mit Menschen: Beziehungen aufbauen, Perspektiven verstehen, Erwartungen klären und gemeinsam Vertrauen entwickeln.