Warum können erfahrene Product-Owner gut einschätzen, welche Features wahrscheinlich Mehrwert bringen – und welche nur nice-to-have sind? Und wie kommt es, dass manche Product-Owner auf einen Blick erfassen, welche Arbeit am Product-Backlog-Eintrag als Nächstes nötig ist?
Das ist nicht einfach nur Erfahrung oder Bauchgefühl. Dahinter steckt mehr:
Wir nennen dies mentale Modelle.
Erfolgreiche Product-Owner wissen, wie leicht im Tagesgeschäft der Überblick verloren geht – zwischen der Erstellung von Product-Backlog-Einträgen, Feedback an die Entwickler und der Abstimmung mit Stakeholdern. Mentale Modelle helfen, den Überblick zu behalten. Sie wirken wie eine innere Landkarte, mit der du schnell erkennst, …
- in welcher Phase der Wertentwicklung sich das Team befindet,
- welche Features wertvoll für das Produkt sind,
- welche Art von Arbeit gerade ansteht – Entdeckung, Validierung oder Delivery.
Hier meine drei Lieblingsmodelle:
Modell #1: Das Logik-Modell
Welche Phasen der Wertentwicklung gibt es?
Diese Frage können wir mit dem Logik-Modell der W. K. Kellogg Foundation beantworten. Hier das Modell im Überblick:
- Ressourcen und Inputs beschreiben, was das Unternehmen investiert, damit Menschen ihre Arbeit tun können. Beispiele: Budget für ein neues Feature, Entwicklungsumgebung, Design-Tools, Testgeräte, Server-Infrastruktur.
- Aktivitäten beschreiben, welche konkreten Arbeiten Menschen in der Organisation verrichten. Beispiele: Anforderungen analysieren, Code schreiben, Prototypen testen, Nutzerfeedback einholen.
- Outputs sind die greifbaren Ergebnisse der geleisteten Arbeit. Beispiele: ein neues Dashboard-Feature, ein verbesserter Onboarding-Prozess, ein überarbeitetes Interface, ein Release-Update.
- Outcomes beschreiben beobachtbare Verhaltensänderungen bei Nutzern durch den Output. Beispiele: 70 % der Nutzer nutzen das neue Dashboard täglich, 40 % schließen den Onboarding-Prozess schneller ab.
- Impacts drücken die Wirkung der Outcomes auf das Unternehmen aus. Beispiele: steigende Nutzerbindung, höhere Conversion-Rate, reduzierte Supportanfragen.
Wie kannst du das Logik-Modell in deiner Arbeit nutzen?
- Verwende das Modell, um in Gesprächen mit Kunden und Vertragspartnern den Unterschied zwischen Input, Output und Outcome sichtbar zu machen.
- Das Modell hilft dir, mit den Entwicklern zu bewerten, welche Outputs wirklich zu gewünschten Outcomes geführt haben.
- Verwende das Modell, um Stakeholdern aufzuzeigen, dass die Inputs, Aktivitäten und Outputs planbar sind. Outcomes und Impacts sind nicht planbar und machen deshalb Iteration nötig.
Wenn wir den Unterschied zwischen Outcome und Output eines Features kennen, stellt sich die Frage:
Welche Features sind wertvoll?
Modell #2: Das Kano-Modell
Gilt nicht einfach: Mehr Features bedeuten mehr Wert?
Lange Zeit sind Unternehmen nur der Prämisse gefolgt, dass mehr Features auch mehr zufriedene Kunden bedeuten. Erst Ende der 1980er Jahre stellte Professor Dr. Noriaki Kano von der Tokyo University of Science das infrage. In seiner Forschung fand er heraus, dass die Kundenbindung von der emotionalen Reaktion auf das Feature abhängt.
Dabei fand er fünf Klassen von Features:
- „Must-Have“-Features: So grundlegende Funktionen, dass sie den Nutzern erst bewusst werden, wenn sie fehlen. Werden die Grundanforderungen nicht erfüllt, entsteht Unzufriedenheit. Werden sie erfüllt, entsteht jedoch noch keine Zufriedenheit.
- Leistungs-Features: Die Nutzer sind sich der Funktionen bewusst. Sie beseitigen Unzufriedenheit oder schaffen Zufriedenheit, abhängig vom Ausmaß der Erfüllung.
- Begeisterungs-Features: Diese Funktionen bieten Nutzen, mit dem der Nutzer nicht rechnet. Sie heben das Produkt von der Konkurrenz ab und rufen Begeisterung hervor.
- Unerhebliche Features: Sowohl ihr Vorhandensein als auch ihr Fehlen sind ohne Belang für den Kunden. Diese Kurve entspricht der vertikalen Achse.
- Zurückweisende Features: Führen bei Vorhandensein zu Unzufriedenheit, bei Fehlen jedoch nicht zu mehr Zufriedenheit des Kunden.
Wobei hilft dir das Kano-Modell?
- Die Einteilung der Features in die fünf emotionalen Reaktionen hilft, die Features im Product-Backlog zu priorisieren.
- Mit dem Kano-Modell kannst du gegenüber Stakeholdern begründen, warum du ihre Anforderung nicht umsetzen wirst.
- Die Einteilung der Features in die fünf emotionalen Reaktionen hilft, die passende Kombination an „Must-Have“- und Begeisterungs-Features zu finden.
Wenn du tiefer ins Management des Product-Backlogs eintauchen willst, dann empfehle ich dir den Besuch des „Professional Scrum Product Backlog Management“-Trainings. Das ist der Kurs zum Product-Backlog-Management – speziell für Product-Owner und alle, die sie coachen wollen!
Nun widmen wir uns der Frage, wie die Entwicklung eines Features abläuft.
Modell #3: Der Double Diamond
Welche Arbeiten sind bei der Entwicklung eines Features nötig?
Diese Frage lässt sich mit dem Double-Diamond-Modell beantworten. Es beschreibt den Ablauf bei der Entwicklung eines Features. Ursprünglich wurde es von der britischen Regierung entwickelt und besteht aus vier Phasen:
- Entdeckung des Problems
- Validierung des Problems
- Entdeckung von Lösungen
- Validierung der Lösungen
Die ersten beiden Schritte beschreiben die Entdeckung eines Eintrags im Product-Backlog. Die letzten beiden Schritte die Entwicklung und anschließende Validierung, ob das Feature das Problem löst.
Hier die Phasen im Detail:
- Entdeckung des Problems: Zunächst wird das Problem aus Unternehmenssicht definiert – durch Einbindung von Stakeholdern oder Analyse interner sowie externer Daten. Im Product-Backlog zeigt sich diese Phase in Form sehr vager Einträge wie „Marktanalyse durchführen“ oder „Kundensegment untersuchen“.
- Validierung des Problems: Anschließend wird geprüft, ob das identifizierte Problem auch aus Sicht der Nutzer relevant ist – etwa durch Interviews oder Umfragen. So wird z. B. ein Backlog-Eintrag durch Kundenfeedback ergänzt und präzisiert.
- Entdeckung von Lösungen: Ein validiertes Problem ermöglicht dem Team, passende Lösungsansätze zu entwickeln – von Ideation über Prototypen bis zu Hypothesen. Im Backlog können hier verschiedene Lösungsideen, erste Skizzen oder geplante UX-Tests dokumentiert werden.
- Validierung der Lösungen: Zum Schluss wird überprüft, ob die Lösung tatsächlich das Problem löst – indem sie ausgeliefert, A/B-Tests gemacht und Kennzahlen erhoben werden. Konkret heißt das: Ein Backlog-Eintrag wird zur Umsetzung freigegeben, im Sprint gebaut und anhand von Nutzerverhalten evaluiert.
Wobei hilft dir der Double Diamond?
- Der Double Diamond hilft dir, zwischen Problemverständnis und Lösungsentwicklung klar zu unterscheiden. Ersteres ist Refinement und Zweiteres Entwicklung im Sprint.
- Das Modell gibt dir Orientierung, welche Art von Arbeit als Nächstes am Product-Backlog-Eintrag ansteht: Entdecken, Validieren, Entwerfen oder Umsetzen.
- Es hilft dir, Stakeholdern zu erklären, dass gute Lösungen nicht nur entwickelt, sondern auch validiert werden müssen. Nur so können wir sicher sein, dass Mehrwert geliefert wurde.
Wenn du mehr dazu erfahren willst, wie du Entdeckung und Validierung in deiner Arbeit als Product-Owner nutzt, dann empfehle ich dir den Besuch des „Professional Product Discovery and Validation“-Trainings. Dort widmen Boris und ich diesem wichtigen Thema, welches in den meisten Scrum-Trainings keine Beachtung findet, einen ganzen Tag.
Zum Abschluss noch ein Modell, das mir die meisten Aha-Momente beschert.
Bonus-Modell: Die Wahrheitskurve
„Experimente sind teuer. Wie viel Aufwand ist gerechtfertigt?“
Bei dieser Frage muss ich mir manchmal auf die Zunge beißen, um nicht zu sagen: „Ein ungenutztes Feature ist noch teurer.“ Trotzdem ist die Frage berechtigt – denn auch Experimente kosten Zeit, Geld und Teamkapazität.
Die Wahrheitskurve nach Giff Constable hilft dir als Product-Owner, Aufwand und 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.
Somit hilft dir die Wahrheitskurve zu entscheiden, welcher nächste Lernschritt sinnvoll ist, ohne zu früh in teure Umsetzung zu verfallen.
Wobei kannst du die Wahrheitskurve nutzen?
- Wenn du noch keine validierten Annahmen hast, reicht oft ein Nutzerinterview oder eine Umfrage, um ein erstes Gefühl für das Problem zu bekommen. Beispiel: Du vermutest, dass Nutzer sich im Onboarding verlieren – frage sie gezielt danach, statt direkt ein neues Tutorial zu bauen.
- Wenn du erste Hinweise hast, kannst du eine Landingpage erstellen, um echtes Interesse zu messen. Beispiel: Du willst wissen, ob ein neues Premium-Feature relevant ist, dann biete es per Fake-Button an und zähle die Klicks.
- Wenn du stärkere Signale brauchst, kannst du eine Preorder-Page oder einen Beta-Test aufsetzen. Beispiel: Lass Nutzer sich für eine neue Integration auf eine Warteliste setzen, bevor ihr sie entwickelt. Das liefert mehr glaubhafte Hinweise als nur eine Umfrage.
- Erst wenn du viele Hinweise gesammelt hast und dir ziemlich sicher bist, lohnt sich der Aufwand, das Feature auch umzusetzen und freizugeben und im Anschluss dessen Performance zu messen – etwa mit Metriken wie Retention, Conversion oder Nutzungsverhalten.
Die Wahrheitskurve hilft dir zu entscheiden, welcher nächste Lernschritt sinnvoll ist, ohne zu früh in teure Umsetzung zu verfallen. Denn: Kleine Experimente vorab sparen dir große Rewrites später.
Zusammengefasst:
Mentale Modelle helfen dir, in der Produktentwicklung nicht den Überblick zu verlieren.
- Mit dem Logik-Modell verstehst du, in welcher Phase der Wertentwicklung sich dein Team befindet.
- Mit dem Kano-Modell kannst du besser entscheiden, welche Features echten Mehrwert bringen.
- Mit dem Double Diamond erkennst du, welche Art von Arbeit als Nächstes ansteht – Entdeckung, Validierung, Entwurf oder Umsetzung.
- Und mit der Wahrheitskurve findest du das richtige Maß an Aufwand für Experimente – abhängig davon, wie viele Hinweise du schon hast.
Willst du noch weitere Modelle kennenlernen, die dich in deiner Arbeit als Product-Owner unterstützen? Dann empfehle ich dir den Besuch des „Professional Scrum Product Owner – Advanced“-Trainings.
198 Product-Owner sind Peters und meiner Empfehlung in den letzten Jahren bereits gefolgt.