Die Produktwerker

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