Wie KI meinen Alltag als Product Owner verändert

In unserem Projekt bei einem etablierten deutschen Modeversandhändler arbeiten mehrere Product Owner, jeder mit einem klar definierten Verantwortungsbereich. Meiner ist die Suche – sowohl die organische Auffindbarkeit im Web als auch die Detailsuche innerhalb des Online-Shops. SEO ist also nicht ein Thema neben meiner eigentlichen Arbeit, sondern Teil davon.

Das bringt eine bestimmte Art von Aufgaben mit sich: datengetrieben, regelbasiert, oft repetitiv. Keyword-Kannibalisierungen in der Google Search Console finden. Ein Regelwerk für SEO-konforme Produktbenennungen auf rund 10.000 Artikel anwenden. Beides ist nicht besonders schwierig. Aber beides ist zeitaufwändig, fehleranfällig … und ehrlich gesagt auch ein bisschen öde.

Kurze Unterbrechung – das Agile-Nachschlagewerk unserer Agile Community

Irgendwann habe ich mich gefragt: Muss ich das wirklich noch selbst tun?

Die Antwort ist differenzierter als ich erwartet hatte. KI ersetzt nicht die Arbeit. Sie verändert, welche Arbeit ich noch selbst tue. Das klingt nach einer Kleinigkeit, ist in der Praxis aber ein echter Unterschied: Ich verbringe weniger Zeit damit, Daten aufzubereiten und Regeln manuell anzuwenden – und mehr Zeit damit, die richtigen Fragen zu stellen und Entscheidungen zu treffen.

Zwei Beispiele aus meiner täglichen Arbeit im Projekt zeigen, was ich damit meine.

Google Search Console mit Claude Code befragen

Was ist Keyword-Kannibalisierung und warum ist sie mühsam zu finden?

Keyword-Kannibalisierung passiert, wenn mehrere URLs einer Website für denselben Suchbegriff ranken. Google weiß dann nicht, welche Seite die relevantere ist – und verteilt den Traffic auf beide, anstatt eine Seite stark zu positionieren. Das Ergebnis: schwächere Rankings, obwohl der Inhalt eigentlich gut ist.

Das Problem zu erkennen ist Fleißarbeit. In der Google Search Console lassen sich Performance-Daten exportieren – aber welche Keywords auf mehreren URLs gleichzeitig ranken, sieht man nicht auf Anhieb. Mein bisheriger Prozess: Daten exportieren, in Excel laden, Pivot-Tabellen bauen, manuell nach Mustern suchen. Für eine fundierte Analyse über 90 Tage mit ausreichend Impressionen für Aussagekraft: mehrere Stunden Arbeit.

Die Lösung: Ein MCP als direkte Schnittstelle

Ich habe Claude Code mit einem sogenannten MCP ausgestattet; einem Model Context Protocol Server. Konkret heißt das: Über das NPM-Paket search-console-mcp kann Claude Code direkt auf meine Google Search Console zugreifen, ohne dass ich Daten exportieren oder aufbereiten muss. Ich stelle eine Frage, Claude holt die Daten und analysiert sie.

Nachher: Fragen statt Exporte

Statt Stunden in Excel zu verbringen, stelle ich jetzt direkte Fragen:

„Welche Keywords ranken im letzten Quartal auf mehr als einer URL gleichzeitig? Sortiere nach Konfliktpotenzial.“

Das Ergebnis kommt in Sekunden. Für das Projekt habe ich so 200 Kannibalisierungskonflikte über einen 90-Tage-Zeitraum analysiert – mit einem quantifizierten Conflict-Score für jeden Fall, der zeigt, wie stark der Traffic aufgeteilt wird.

Das Muster, das dabei deutlich wurde: Ein Großteil der Konflikte entstand durch doppelte Kategorie-URLs – dieselbe Kategorie war unter zwei verschiedenen Pfaden erreichbar, die gleichzeitig für dieselben Keywords rankten (Conflict-Score: 0.69–0.84). Ein klassischer technischer SEO-Fehler, der im Rauschen der Daten leicht untergeht.

Was mich am meisten überrascht hat: nicht die Geschwindigkeit, sondern die Folgefragen, die ich dadurch erst stellen konnte. Wenn eine erste Antwort in Sekunden kommt, kann ich sofort vertiefen: „Welche dieser Konflikte haben die höchste Sichtbarkeit?“ oder „Gibt es Ausnahmen, wo beide URLs absichtlich parallel existieren?“ Dieser Gesprächsrhythmus wäre mit manuellen Exporten schlicht nicht möglich.

SEO-Regeln auf tausende Produkte anwenden

Das Problem: Ein Regelwerk, das niemand konsequent anwendet

Bei unserem Kunden gibt es ein detailliertes Regelwerk dafür, wie neue Produktbezeichnungen SEO-konform aufgebaut werden müssen. Maximallänge 50 Zeichen. Standardmaterialien wie Polyester oder Viskose werden nicht erwähnt, Premiummaterialien wie Seide oder Kaschmir schon. Modellnamen werden in Titelschreibweise angegeben, nicht in Großbuchstaben. Keine Anführungszeichen. Keine Formulierungen mit „ohne“ (also nicht „ohne Arm“, sondern „ärmellos“). Und so weiter.

Das Regelwerk existiert als Excel-Datei. Und solange jemand neue Artikel benennt, müsste diese Person bei jedem Namen manuell prüfen, ob alle Regeln eingehalten sind. In der Praxis passiert das entweder gar nicht, oder es dauert unverhältnismäßig lang.

Was ich Claude gegeben habe

Ich habe Claude Code das Regelwerk als Kontext gegeben, zusammen mit der Produktliste aus dem Master-Feed: rund 10.000 Artikel mit Namen und Beschreibungen.

Die Frage war im Grunde, welche dieser Produktbezeichnungen gegen welche Regeln verstoßen – und wie sie korrekterweise heißen sollten.

Was herauskam

Claude hat alle rund 10.000 Produkte gegen das Regelwerk geprüft und für jedes Produkt einen SEO-Status vergeben:

Status: OK – Anzahl: 9.086 – Anteil: 98,3 %
Status: Prüfen (1 Verstoß) – Anzahl: 149 – Anteil: 1,6 %
Status: Überarbeiten (2+ Verstöße) – Anzahl: 4 – Anteil: 0,0 %

Probleme: unnötige Ärmelangaben bei Produkten, bei denen das Format erwartet wird (85 Fälle), Anführungszeichen in Modellnamen (43 Fälle), Modellnamen in Großbuchstaben statt Titelschreibweise (18 Fälle).

Ein konkretes Beispiel: Ein Produkt war mit “Hemd-Bluse „CLEO““ eingetragen, also Anführungszeichen und Großbuchstaben gleichzeitig. Die Regel besagt: Anführungszeichen entfernen, Modellname in Titelschreibweise. Korrekt wäre also: Hemd-Bluse Cleo. Claude hat das erkannt, den Verstoß benannt und den korrekten Namen vorgeschlagen. Für alle rund 10.000 Produkte. In einem Durchlauf.

Das Wichtige dabei: Claude hat nicht entschieden. Es hat geprüft. Die inhaltliche Arbeit – das Regelwerk zu definieren, die Ausnahmen festzulegen (bestimmte Markennamen dürfen abweichend geschrieben werden), den Umgang mit Grenzfällen zu klären – das war meine Aufgabe. Claude hat diesen Kontext genutzt, um eine Aufgabe zu erledigen, die sonst Tage gedauert hätte.

Was hat sich wirklich verändert?

Ich werde gefragt, ob KI mir Arbeit abnimmt. Die ehrliche Antwort: Manchmal. Aber das ist nicht der eigentliche Gewinn.

Der eigentliche Gewinn ist, dass ich schneller im Dialog bin. Wenn eine Analyse nicht Stunden, sondern Minuten dauert, verändert sich der Umgang mit Erkenntnissen grundlegend. Ich hinterfrage mehr, gehe tiefer, teste alternative Annahmen – weil es sich lohnt, weil es keinen halben Arbeitstag kostet. Früher habe ich eine Kannibalisierungs-Analyse als Quartalsaufgabe betrachtet. Heute ist sie eine Frage, die ich bei Bedarf stelle.

Was ich dabei gelernt habe: Kontext ist alles. Claude Code liefert keine Magie, es liefert strukturierte Ergebnisse auf Basis dessen, was ich einbringe. Wer unpräzise fragt, bekommt ungenaue Antworten. Wer das Regelwerk nicht kennt, kann es nicht übergeben. Die fachliche Tiefe bleibt bei mir, die KI übernimmt die Ausführung.

Und das bedeutet auch: Der Einstieg in diese Arbeitsweise kostet Zeit. Man muss lernen, wie man Kontext aufbaut, wie man Aufgaben so beschreibt, dass sie ausführbar sind. Das erste Mal dauert länger. Das zweite Mal geht schneller. Beim dritten Mal denkt man nicht mehr darüber nach.

Das klingt nach einer Selbstverständlichkeit. Ist es aber nicht. Es ist eine Arbeitsweise, die sich erst durch Ausprobieren erschließt – und die, einmal etabliert, schwer wieder aufzugeben ist.

Als Product Owner „mal KI ausprobieren“

Ich würde niemandem empfehlen, einfach „mal KI auszuprobieren“. Ich würde empfehlen, eine konkrete, wiederkehrende Aufgabe zu nehmen – eine, die regelbasiert ist, auf Daten beruht und regelmäßig Zeit kostet – und diese Aufgabe einmal mit Claude Code zu versuchen.

Für POs ist der Einstieg oft dort, wo es am unspannendsten ist: Daten aufbereiten, Regelwerke prüfen, Listen analysieren. Genau diese Aufgaben sind KI-tauglich. Weil sie klar strukturiert sind und weil der fachliche Kontext, der dafür nötig ist, bereits im Projekt vorhanden ist.

Der Rest ist eine Frage der richtigen Fragen.

Wenn ihr in eurem Projekt ähnliche Herausforderungen kennt – zu viele Daten, zu wenig Zeit, Regelwerke die niemand konsequent anwendet – sprecht uns gerne an. Wir helfen dabei, den richtigen Einstieg für euren Kontext zu finden.