Die Produktwerker

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.