Die Produktwerker Archiv

Katja Busch, Autorin des Buchs „Experience Management als Future Skill“, spricht mit Dominique darüber, warum gute Produkte allein nicht mehr reichen. In gesättigten Märkten entscheiden nämlich Erlebnisse darüber, ob Menschen wiederkommen oder zur Konkurrenz wechseln. Experience Management geht deshalb über UX und CX hinaus. Es muss in Unternehmensprozessen verankert und auf Entscheiderebene vertreten sein. Dafür braucht es die Sprache des Business. Nicht das bessere Erlebnis überzeugt, sondern Effizienz, Effektivität und Wettbewerbsvorteile. Menschen meiden unnötigen Aufwand und wechseln, sobald sie eine einfachere Alternative kennen. Vieles davon geschieht unbewusst. Product Owner und Product Manager sollten deshalb weniger in Features als in gewünschtem Verhalten denken: Was muss die Zielgruppe tun, damit ein Produkt wirtschaftlich erfolgreich ist? Angebote können Verhaltensänderungen erleichtern. Statt unter Druck reflexartig mehr Marketing zu betreiben oder Kosten zu senken, sollten Unternehmen die Ursachen verstehen. Eine kontinuierliche Wettbewerbsbeobachtung mit KI hilft dabei. Veränderung gelingt am ehesten dort, wo ein businesskritisches Problem neue Ansätze verlangt. Leuchtturmprojekte und eigene Erfahrungen überzeugen mehr als Vorgaben von oben. Interviews, Beobachtungen und Stakeholderanalysen helfen, den internen Kontext zu verstehen. Positive Erlebnisse und Emotionen machen Veränderung leichter. KI beschleunigt die Discovery, kann aber das kritische Denken schwächen. Product Teams brauchen Raum für die richtigen Fragen und sollten Ergebnisse testen, statt Annahmen zu übernehmen. Denn KI kennt nicht automatisch den Unternehmenskontext. Viele Features bleiben ungenutzt, ohne dass Teams ihre Nutzung überhaupt messen. Ein schneller Test bringt oft mehr als die nächste Annahme. Katjas wichtigster Rat lautet: „Be the business“. Wer versteht, welche Erfahrungen Entscheider brauchen, schafft bessere Bedingungen für die eigene Arbeit. Ihr Buch „Experience Management als Future Skill“ vertieft das Thema.

Dominique und Tim sprechen im dieser Folge über ein Problem, das fast jede Produktverantwortung kennt. Wenn das Operative das Strategische verhindert, drehen sich Teams im Kreis. Bugs beheben, Kundenwünsche erfüllen und laute Stakeholder bedienen fühlt sich fleißig an. Das Team ist ausgelastet und die Velocity stimmt. Aber trotzdem entwickelt sich das Produkt in Richtungen, die niemand geplant hat. Am Ende steht dann ein Produkt, das überall ein bisschen mitmischt und dessen Richtung keiner mehr klar erklären kann. Beschäftigung ist eben nicht unbedingt Fortschritt. Das Operative gewinnt, weil es laut, konkret und dringend ist. Meldet der Kundenservice den zehnten betroffenen Nutzer des Tages, verlangt das sofortige Reaktion. Strategische Arbeit ist wichtig, aber selten dringend, und das Wichtige kann ja auch morgen noch warten. Dazu kommt die soziale Seite. Wer schnell hilft, erntet direkt Dank und Anerkennung. Wer eine strategische Wette vorbereitet, hört erst nach anderthalb Jahren die Frage, was sich bewegt hat. Wer es allen recht machen will, schiebt die eigene Arbeit in Nachtschichten oder lässt sie liegen. Der Schmerz bleibt dabei klein, denn strategische Entscheidungen wirken zeitverzögert. Strategische Arbeit dageben braucht Raum, und zwar doppelt. Ein Blocker im Kalender macht klarer sichtbar, wie viel Zeit das Thema tatsächlich bekommt. Dazu gehört ein Raum ohne Ablenkung. Hilfreich sind feste Kanten, etwa der Montagmorgen vor der ersten Mail oder zwei Stunden vor dem Wochenende. Der "Nicht stören"-Modus am Handy hält andere fern, und für echte Notfälle gibt es klare Ausnahmen. Wer allein nachdenkt, sortiert Gedanken und bewertet Optionen. So geht niemand unvorbereitet in den Austausch mit anderen. Trotzdem bleibt Strategie aber weiterhin ein Teamsport. Regelmäßige Termine mit Stakeholdern oder einem Product Advisory Board schaffen Verbindlichkeit, denn wer etwas vorstellen muss, bereitet sich vor. In der Runde selbst hilft Timeboxing. Operative Themen rutschen in die letzte Viertelstunde, die Strategie kommt zuerst. Nichts fällt weg, doch nichts frisst den Termin auf. Damit alle dasselbe unter Strategie verstehen, helfen greifbare Ergebnisse. Ein Product Goal für sechs bis zwölf Monate, eine Produktvision oder die Frage, welchen Horizont das Team gerade betrachtet, geben Orientierung. Auch Roadmap oder Six Pager setzen eine Frist und machen Strategie dringlich. Führungskräfte entscheiden mit, ob strategische Arbeit Platz bekommt. Loben sie nur schnelle operative Reaktionen, richtet das Team sich danach aus. Fragen sie dagegen nach Erkenntnissen statt nur nach Sprintergebnissen, ändert sich das Verhalten. Gelebte Strategie zeigt sich in Entscheidungen, also im begründeten Nein zu manchen Dingen und im begründeten Ja zu anderen. Ein Papier im Schrank bringt nichts. Der Decision Stack prüft die Kette: Die User Story dient dem Sprintziel, das Sprintziel dem Produktziel, das Produktziel der Vision. Selbst ein Bugfix zahlt darauf ein, denn Menschen sollen das Produkt nutzen können. Dominique und Tim geben euch am Ende drei Reflexionsfragen mit: Wie viel Zeit fließt wirklich in strategische Arbeit? Eine Strichliste über zwei, drei Wochen liefert die Antwort. Zeigen Führungskräfte, dass ihnen diese Arbeit wichtig ist, und bitten sie ihr Team um Hinweise auf operative Ablenkung? Und hängt das Tagesgeschäft sichtbar mit der Ausrichtung zusammen? Operative Arbeit geht nie aus. Wenn das Operative das Strategische verhindert, hilft deshalb vor allem eine bewusste Entscheidung für feste Zeiten. Zum Schluss lohnt die Frage: Was antwortet ihr nach anderthalb Jahren, wenn jemand wissen will, was ihr am Produkt verändert habt?

Was sind synthetische Nutzer? Peter Rochel von Oberwasser Consulting und führender "Jobs-to-be-Done"-Experte ist in dieser Folge erneut bei Tim zu Gast und erklärt was genau synthetische Nutzer sind und was sie taugen. Klassische Jobs to be done Interviews liefern tiefe Einblicke, kosten aber viel Zeit. Ein Gespräch dauert rund anderthalb Stunden (je nach B2C oder B2B) und die Auswertung schluckt noch einmal das Doppelte. Kein Wunder, dass KI als Abkürzung lockt. Bei synthetischen Nutzern übernimmt ein Sprachmodell die Rolle des Kunden, ein zweiter Bot führt das Interview. Peter Rochel nennt das Ergebnis "Synterview", eine Mischung aus synthetisch und Interview. Schon seit 2023 probiert er das intensiv aus, zunächst mit Custom GPTs, die sein gesamtes Beratungswissen kennen, inzwischen mit agentischer KI. Die Ergebnisse überraschen durchaus positiv. Beim Nachstellen echter Projekte liefern synthetische Nutzer brauchbare Muster, vor allem bei den Pains und Gains in Bezug auf die Jobs für die sie Produkte und Services "beauftragen". Trotzdem bleibt ein ungutes Gefühl, denn die Antworten klingen zwar plausibel, wirken aber oft so glatt als stünden sie in einem Marketingprospekt. Hinzu kommt die Neigung der Modelle zu halluzinieren, was sich je nach Anbieter unterscheidet. Peter Rochel empfiehlt: Wer ernsthaft damit arbeiten möchte, baut am besten mehrere Kontrollschichten ein und gleicht alles ab, was sich automatisch prüfen lässt. Ohne Interviewerfahrung fällt es jedoch schwer, solche Schwächen überhaupt zu bemerken. Wobei wir wieder bei einer der Kernthesen der Arbeit mit AI Systemen wären: Du musst wissen "How good looks like"! Die Grenze liegt für Peter bei den Auslösern von Progress. Warum jemand genau in diesem Moment wechselt, bleibt für synthetische Nutzer fast unerreichbar. Trigger Events wie ein Umzug, eine Trennung oder die Geburt eines Kindes erklären z.B., warum jemand plötzlich den höhenverstellbaren Schreibtisch kauft, über den er seit Jahren nachdenkt. Ein Modell kennt nur, was in seinen Daten steckt. Wirklich Neues entdeckt es nicht, und Verhalten sagt es kaum voraus. Deshalb lohnt die Kombination: Synthetische Interviews liefern allgemeine Muster, echte Gespräche den spezifischen Kontext. Beim Aufbau des Kandidatensets hilft die Taguchi Methode, die gezielt die Ausreißer an den Rändern abdeckt, denn dort steckt der größte Lerneffekt. Billiger sind synthetische Interviews nicht in jedem Fall. Der echte Hebel liegt in der Auswertung. Wo früher drei gut ausgebildete Personen eine Woche lang Muster aus zehn Interviews herausarbeiten, erledigt die KI das in wenigen Stunden, und selbst 200 Euro für Token fallen da kaum ins Gewicht. Die Projektkosten sinken so auf rund 16.000 Euro - früher lagen sie fast beim Dreifachen. Vollautomatische Anbieter aus Nordamerika liefern fertige Studien in Minuten, verlangen dafür aber etwa 30k Dollar im Jahr. Auftraggeber trauen synthetischen Ergebnissen zudem weniger, denn ein echter Mensch mit echter Erfahrung berührt stärker als eine Berechnung. Dazu kommt der Aufbau von Empathie bei der Auswertung. Teams, die Muster selbst auswerten, verinnerlichen die Sicht ihrer Kunden. Eine automatisierte Auswertung, die man nur überfliegt, ersetzt das nicht. Zwei Charts in einer Präsentation reichen nicht, um zu wissen, wie Kunden ticken. Sinnvoll sind synthetische Nutzer laut Peter Rochel in jedem Fall dort, wo echte Kandidaten fehlen. Aber natürlich auch bei kleinen Unternehmen mit knappem Budget. Dort ist ein günstiger Einstieg besser als gar keiner, solange man weiß, dass er nur der Anfang ist. Doch sollte jetzt jeder auf synthetische Interviews umsteigen? Wer kann, führt Interviews weiter selbst und lässt sich bei der Auswertung von KI helfen, denn dort steckt der meiste Aufwand. Fehlen Zugang oder Know how, taugen eingekaufte Interviews synthetischer Nutzer als Start. Vorher steht immer die Frage nach dem Ziel. Bleibt die Antwort offen, spart man sich das Projekt besser.

Wie wissenschaftlich muss Produktarbeit eigentlich sein? Dieser Frage gehen Oliver und Dominique in der aktuellen Folge nach. Denn Product Owner verlassen sich häufig auf Erfahrung, bewährte Methoden und Bauchgefühl. Doch wie belastbar sind Entscheidungen, die vor allem auf Intuition beruhen? Wissenschaftliches Arbeiten kann helfen, bessere Entscheidungen zu treffen, ohne gleich jedes Product Backlog Item zur Forschungsstudie zu machen. Dazu gehört, selbst Erkenntnisse durch User Research, Datenanalysen und Experimente zu gewinnen, aber auch vorhandene Forschung kritisch zu nutzen. Dabei lauern zahlreiche Denkfallen. Aus einzelnen Erfolgsgeschichten werden vermeintliche Best Practices, Korrelation wird mit Kausalität verwechselt und persönliche Überzeugungen verdrängen belastbare Erkenntnisse. Gleichzeitig halten sich längst überholte Modelle wie Persönlichkeitstypologien mit Farben hartnäckig in der Praxis. Doch wissenschaftliche Genauigkeit hat auch ihren Preis. Nicht jede Produktentscheidung rechtfertigt aufwendige Untersuchungen. Entscheidend ist vielmehr, wie hoch das Risiko einer Fehlentscheidung ist und wie viel Evidenz benötigt wird, um dieses Risiko verantwortungsvoll einzugehen. Oliver und Dominique diskutieren deshalb, wie evidenzinformierte Produktarbeit gelingen kann, warum kritisches Denken wichtiger ist als die perfekte Methode und wie Product Owner mit HIPPOs, ZEBRAs und organisatorischem Gegenwind umgehen können.

Hackathons bieten Product Ownerinnen und Product Ownern einen geschützten Rahmen, um Ideen jenseits des Sprintalltags zu erproben. Oliver spricht mit Andrea aus dem IT-Portfoliomanagement und Tech Lead Lukas über die internen Hackathons bei OBI: Wie entstehen aus Ideen Prototypen, welche Rolle übernehmen Product Owner und was lässt sich in die tägliche Produktentwicklung mitnehmen? Außerdem geht es um die Weiterverfolgung der Ergebnisse und praktische Learnings zu Organisation, Kommunikation und Verpflegung.

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? Was glaubt Ihr?

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

Was ist eigentlich das Produkt? Die Frage klingt trivial, ist für viele Product Owner aber alles andere als leicht zu beantworten. In dieser Folge spricht Oliver mit Philipp Weiß, Product Owner der Website bei Transfermarkt.de, über genau diese Frage an einem konkreten Praxisfall. Transfermarkt ist seit 26 Jahren die größte öffentlich zugängliche Fußballdatenbank der Welt, mit Profilen, Marktwerten, News, Forum, Spielen und Tools, in 16 Sprachen, dazu App und B2B-Angebot. Ist bei dieser Bandbreite einfach die ganze Website das Produkt? Und wie lassen sich Produktvision, North Star Metric und Strategie auf dieser Ebene sinnvoll nutzen? Oliver und Philipp gehen mögliche Produktschnitte durch: nach Kanal, nach Inhalt, nach Teamstruktur oder nach Nutzerbedürfnissen. Sie sprechen darüber, was jede Variante für Priorisierung und Zusammenarbeit bedeutet, warum sich Organisationen so schwer von gewachsenen Features trennen und warum der Fokus auf wenige Spielfelder oft wichtiger ist als der perfekte Produktschnitt. Eine Folge für alle Product Owner mit gewachsenen, komplexen Produkten, auch für Hörer:innen ohne Fußballbezug.

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/

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

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](https://mattlemay.com/books)" 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](https://jeffgothelf.com/blog/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.

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.

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.