Beim Wort „Product-Owner“ denken viele an große Visionäre:
Etwa an Gates, Jobs oder Musk.
Wie mir diese Umfrage mal wieder bestätigt. Ich habe sie nach dem letzten Webcast „Product Backlog Management Skills“ erstellt, um ein Thema für die nächste Show zu finden. Ich wollte wissen, über welche Product-Owner-Haltung die Agile-Community mehr erfahren will.
Und mit Abstand die meisten interessierten sich für den Visionär.
Warum Product-Owner mehr als nur Visionäre sind
Was macht visionäre Product-Owner aus?
Visionäre Product-Owner konzentrieren sich auf die Vision, den zukünftigen Zustand des Produkts und die Möglichkeiten, Ziele und Chancen zu erkennen. Sie richten ihr Augenmerk darauf, was sein könnte, anstatt auf das, was ist.
Daneben gibt es aber noch andere Haltungen:
- Der Kundenvertreter: Als Vertreter des Kunden versucht der Product-Owner, die Probleme, Schmerzen und Chancen der Kunden wirklich zu verstehen. Es geht darum, sich in die Lage des Kunden zu versetzen.
- Der Entscheider: Aus dieser Perspektive konzentriert sich der Product-Owner darauf, gute Entscheidungen zu treffen. Welche Elemente sollen zum Product-Backlog hinzugefügt werden? Was ist das nächste große Ziel? Welche Kunden sollen zufriedengestellt werden und welche nicht?
- Der Experimentierer: Dies ist die Perspektive auf Innovation, Experimente und neue Dinge. Als Experimentierer denken Product-Owner über Risiken, Hypothesen, Tests, Erkenntnisse und Daten nach. Beim Experimentierer geht es weniger darum, neue Dinge zum Produkt hinzuzufügen, als darum, dessen Wert zu validieren.
Diese drei Haltungen werden häufig weniger beachtet – nicht nur in der Umfrage, sondern auch in meinen Schulungen oder wenn ich mit Kunden arbeite.
Allerdings wird hier eine wichtige Tatsache über die Entwicklung von Produkten sträflich übersehen.
Warum jedes Produkt auf Experimenten basieren sollte
Du kennst bestimmt auch die Aussage: Neun von zehn Start-ups erleben nicht das zweite Jahr nach ihrer Gründung.
Mit Ideen für Produkte oder Features verhält es sich ganz ähnlich. Im Jahr 2009 hat Microsoft die Arbeit „Online Experimentation at Microsoft“ veröffentlicht und öffentlich bestätigt:
- Nur etwa ein Drittel der Ideen verbessert die Kennzahlen, für die sie entwickelt wurden.
- Ungefähr ein Drittel der Ideen liefert ein negatives Ergebnis (schadet also mehr), und
- etwa ein Drittel der Ideen liefert kein Ergebnis (es entstand also keine signifikante Veränderung).
Und Microsoft ist damit nicht allein. Bei Amazon beispielsweise ist es gängige Praxis, jede neue Funktion zu bewerten, dennoch liegt die Erfolgsquote unter 50 %.
Zum Abschluss noch ein Beispiel, was mit Ideen oder Funktionen gemeint ist. Betrachten wir etwa die Verbesserung oder Verschlechterung der Geschwindigkeit bei der Suche auf einer Webseite.
„Es hat sich herausgestellt, dass eine Verzögerung, die nur einen Wimpernschlag dauert – etwa 400 Millisekunden –, Nutzer abschrecken kann. Im vergangenen Jahr hat Google experimentell eine Verzögerung von 400 Millisekunden bei der Bereitstellung von Suchergebnissen eingeführt. Die Suchanfragen pro Nutzer gingen zurück. Nach sechs Wochen waren die Suchanfragen pro Nutzer um fast ein Prozent zurückgegangen. Diese scheinbar geringe Zahl entsprach mehreren hundert Millionen Dollar pro Jahr an potenziellen Werbeeinnahmen.“
Bei Amazon zeigt sich sogar, dass die Verzögerung von 100 Millisekunden zu einem Umsatzrückgang von 1 % führte.
Wir können also getrost festhalten: Viele Ideen für Produkte und Funktionen werden sich als Flop entpuppen.
Warum unsere menschlichen Vorhersagen (fast immer) falsch sind
Deshalb braucht es die Einstellung des Experimentierers.
Es geht im Kern darum, sich darauf einzulassen, sich zu irren. Sich als Product-Owner auf Experimente einzulassen, ist am Ende somit eine Übung in Demut.
Demut ist eine Herausforderung.
So auch bei Microsoft. Einige Mitarbeiter bei Microsoft sahen das Experimentieren als Bedrohung für ihre Macht und ihr Prestige, da es ihre Rolle als Entscheider infrage stellte. Aussagen wie: „Wir wissen, was zu tun ist. Es liegt in unserer DNA“, zeigten die Überzeugung, die Ergebnisse ohne Daten vorhersagen zu können.
Deshalb entwarfen die Autoren einen Test.
Sie nannten ihn das HiPPO-Quiz. Das Ziel war, ihre Kollegen und Mitarbeiter davon zu überzeugen, dass sie die Ergebnisse von Experimenten nicht gut vorhersagen können. Dazu wurde eine Umfrage mit acht A/B-Tests durchgeführt. Die Teilnehmer mussten für jeden Test die korrekte statistisch signifikante Option wählen (A ist besser, B ist besser oder kein signifikanter Unterschied).
Das Ergebnis: Von über 200 Teilnehmern lag keiner bei mehr als sechs von acht Tests richtig. Der Durchschnitt der korrekt geratenen Antworten lag bei 2,3. Dies war ein ernüchterndes Ergebnis. Es zeigt, wie schlecht Experten darin waren, den Wert von Funktionen einzuschätzen.
Soll heißen:
Product-Owner, die rein auf ihre Expertise und Erfahrung vertrauen und Entscheidungen treffen, welche Funktionen entwickelt werden sollen, welche Einträge im Product-Backlog oben stehen sollten oder welche Strategie die richtige ist – also in der Haltung des Entscheiders verharren –, schaden dem Unternehmen mehr, als sie nützen.
Deshalb ist die Haltung des Experimentierers die am häufigsten übersehene Haltung, die Product-Owner einnehmen müssen.
Das Werkzeug, das unsere Unzuverlässigkeit ausgleicht
Die Lektion aus den Erfahrungen von Microsoft sollte somit lauten:
Teste jedes Feature, jede Funktion und jedes Produkt vor dem Release mit A/B-Tests. Für Unternehmen wie Facebook, Amazon, Netflix und Google mag dies praktikabel sein, für viele andere jedoch zu kostspielig. Wir brauchen also ein Vorgehen, das uns erlaubt, Ideen bereits günstiger zu testen.
Das Werkzeug ist die Wahrheitskurve nach Giff Constable.
Sie hilft, den Aufwand und den Erkenntnisgewinn ins richtige Verhältnis zu setzen. Sie zeigt:
Je höher der Aufwand eines Experiments ist, desto glaubhafter sind auch die Erkenntnisse, die du daraus gewinnst, – und umgekehrt.
Oder anders ausgedrückt: Mit beschränkten Ressourcen und finanziellen Mitteln und bei wenigen Hinweisen, dass diese Funktion Mehrwert liefern wird, sollten wir ein kostengünstiges Experiment nutzen, um Hinweise zu erhalten, ob die Idee wertvoll ist oder nicht.
Es geht darum, kleine – und viele – Einsätze zu tätigen, um mehr zu lernen – ähnlich wie beim Poker.
Aber leider denken immer noch viele Product-Owner, dass sich Produktmanagement mit Schach vergleichen lässt.
In Wetten denken – das DIBB-Framework erklärt
Was unterscheidet Poker von Schach?
Beim Schach liegen alle Spielfiguren auf dem Tisch. Obwohl Schach ein schwieriges Spiel ist, insbesondere gegen brillante Spieler, sind alle Informationen auf dem Brett zu sehen.
Beim Poker sind die einzigen bekannten Informationen die eigenen Karten sowie die Karten, die auf dem Tisch liegen. Du weißt nicht, welche Karten die anderen Spieler haben. Du weißt nicht, welche Karten in der nächsten Runde aus dem Stapel gezogen werden.
Daher ähnelt die Produktentwicklung am ehesten dem Poker. Denn es gibt viel mehr Unbekanntes als Bekanntes. Es sind niemals alle Informationen transparent. Und obwohl Fähigkeiten und Professionalität eine Rolle spielen, gibt es immer ein Element von Glück und Pech.
So wie im Produktmanagement.
Ein schlanker Entscheidungsrahmen, um als Product-Owner wie ein Pokerspieler zu denken, wurde vor einigen Jahren von Spotify beschrieben. Es geht darum, aus Fakten („Data“) handlungsfähige Wetten („Bets“) abzuleiten – sichtbar gemacht z. B. über ein Bets-Board und laufend per Feedback-Loop überprüft.
- Data: Beobachtbare Fakten und Signale (Metriken, Trends, Nutzerforschung)
- Insight: Bedeutung und Diagnose aus den Daten (Was steckt wirklich dahinter?)
- Belief: Klar formulierte Annahme und Hypothese, die wir für wahr halten
- Bet: Konkrete Initiative, mit der wir die Annahme testen und Wert liefern wollen (inkl. Erfolgskriterien)
Dieses Framework wird häufig als DIBB bezeichnet.
Wir können die Wahrheitskurve nun nutzen, um den Einsatz oder die Investition in die Wette passend zu den Daten als den marktbasierten Hinweisen zu wählen.
Wie können solche Experimente innerhalb des DIBB-Frameworks aussehen?
Beispiele für wirkungsvolle Produkt-Experimente
Hier eine Liste von Experimenten.
Diese Liste nutzen Peter und ich auch im „Professional Scrum Product Owner – Advanced“-Training, wenn wir die Teilnehmer in die Haltung des Experimentierers schlüpfen lassen.
- Papierprototypen: Mit Papierprototypen können mögliche Designs schnell und kostengünstig erstellt und getestet werden.
- Vorbestellungsseite: Auf einer Vorbestellungsseite können sich Interessenten vor der offiziellen (öffentlichen) Markteinführung für ein Produkt oder Feature anmelden, sodass Unternehmen das Interesse daran einschätzen können.
- Erklärvideos: Diese Videos erklären, wie ein Produkt oder eine Dienstleistung funktioniert, ohne dass das Produkt vollständig funktionsfähig ist.
- Landing-Pages: Landing-Page-Experimente dienen als Werbung für eine Idee. Sie bieten ein Wertversprechen, einen Aufruf zum Handeln und einen Konversionsmechanismus.
- Feature-Fake: Feature-Fake-Experimente vermitteln mit einem Button oder einem Link die Illusion einer Funktion, führen aber in eine relative „Sackgasse“.
- Concierge-MVP: Es werden alle Funktionen des Produkts manuell ausgeführt und das Team arbeitet direkt mit jedem Kunden zusammen, um sein Problem zu lösen.
- Wizard of Oz: Der Wizard of Oz ist ein Experiment, bei dem ein Benutzer mit einer Produktschnittstelle interagiert, die autonom erscheint, aber tatsächlich (ganz oder teilweise) von einem Menschen im Hintergrund gesteuert wird.
Zum Schluss noch zum Elefanten im Raum:
Meine Einschätzung: Welche Auswirkungen hat KI auf die Wahrheitskurve?
Die Wahrheitskurve verschiebt sich durch KI deutlich nach links unten.
Mit weniger Aufwand erhältst du belastbarere Hinweise – besonders in den frühen Phasen. Text-zu-Prototyp-Werkzeuge, synthetische Nutzerforschung und KI-gestützte Marktanalysen verkürzen Lernzyklen von Wochen auf Tage oder Stunden.
So können Product-Owner viele Schritte bei der Validierung eigenständig durchführen, bevor sie UX-Researcher, Designer oder Entwickler beauftragen, Kundenberatungen, Marktforschung oder A/B-Tests durchführen.
Praktisch heißt das:
- Erste Prototypen aus Textbeschreibungen erzeugen und sofort mit realistischen Nutzeraufgaben testen. Die Hinweise kommen an „echte“ Klick-Prototypen heran, bei deutlich geringerem Aufwand.
- Synthetische Interviews und skalierte Umfragen nutzen, um Hypothesen grob zu sortieren, bevor aufwendigere Marktforschung genutzt wird. Das spart Zeit und hilft, die richtigen Fragen an echte Nutzer zu priorisieren.
- KI-unterstützte A/B-Logik einsetzen (Priorisierung, Traffic-Steuerung), sobald echte Nutzerkontakte vorhanden sind – mehr Hinweise bei ähnlichem Implementierungsaufwand.
- LLM-gestützte Markt- und Wettbewerbsanalysen verwenden, um Signale aus Datenmengen zu heben, die früher nur mit großem Rechercheteam möglich waren.
Dabei ist mir wichtig, zu betonen:
KI beschleunigt den Weg zur Wahrheit, ersetzt aber nicht die schrittweise Validierung. Niedriger Aufwand kann heute überraschend hohe Plausibilität liefern, kann aber dazu verführen, auf spätere, teurere Prüfungen zu verzichten.
Wenn du mehr darüber lernen willst und konkret diese Techniken auch selbst ausprobieren möchtest, dann empfehle ich dir den Besuch des „Professional Scrum Product Owner – Artificial Intelligence“-Trainings.
Zum Abschluss mein Appell:
Als Product-Owner ein Visionär zu sein reicht nicht; ohne Experiment-Haltung verbrennst du nur Budget.