Die Produktwerker

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.