Im Jahr 2026 lautet die Frage nicht mehr:„Wie schnell kann das Team liefern?“Sondern die Frage lautet: „Ist das Gelieferte wertvoll?“ KI erzeugt einen neuen Flaschenhals in der Produktentwicklung. Die Entscheidung, woran das Team arbeiten soll, wird zur Engstelle. Jeff Sutherland prophezeite bereits auf LinkedIn, dass das Zeitalter des „Human-in-the-Loop“ bereits zu Ende ist.So drastisch sehe ich es (noch) nicht.Allerdings legt der Einsatz von KI in der Softwareentwicklung den Finger in eine Wunde, die bisher verborgen war. Viele Unternehmen sind mit mittelmäßigen Entscheidungen noch gut weggekommen. Am Ende des Projekts war einfach jeder froh, dass irgendetwas fertig wurde.Deshalb wurde gerne darüber hinweggesehen,ob das Feature den Schmerz der Nutzer wirklich löste,ob es gern genutzt wurde,ob Kunden bereit waren, dafür zu bezahlen, undob es den erwarteten Gewinn für das Unternehmen einlöste.Diese Zeit ist vorbei.Versteh mich bitte nicht falsch. Wenn ich von besseren Entscheidungen spreche, dann spreche ich nicht davon, dass wir den erwarteten Gewinn exakt vorhersagen können müssen. Produktmanagement bleibt weiterhin ein Spiel mit Ungewissheit. Product-Owner können den Sieg nicht garantieren.Allerdings können wir uns absichern, ob wir bestmöglich entschieden haben.Darum geht es beim evidenzbasierten Produktmanagement im Kern. In dieser Ausgabe von „Scrum mit KI“ möchte ich einen Aspekt aus meinem Training mit dir beleuchten. Wie treffen wir bessere Entscheidungen (mit KI)? Los geht’s ...Warum 65 % unserer Entscheidungen von Anfang an falsch getroffen wurden Wir fragen uns:„Sollten wir dieses Kundenbedürfnis lösen?“„Sollten wir dieses Feature entwickeln?“„Sollten wir diesen Bug beheben?“Dies ist kein Zufall. Es handelt sich um ein tief verankertes psychologisches Muster.Baruch Fischhoff, Professor an der Carnegie Mellon University, befragte 105 Teenager-Mädchen, welche Entscheidungen sie zuletzt getroffen hatten, und erkannte: 65 % davon waren keine echten Wahlentscheidungen gewesen.Die Entscheidungen beantworteten lediglich Fragen der Art: „Soll ich heute zur Schule gehen oder nicht?“Unbewusst tappen Product-Owner täglich in dieselbe Falle. Wer fragt: „Sollten wir dieses Feature entwickeln?“, hat den Entscheidungsrahmen bereits auf Ja oder Nein verengt, bevor er überhaupt weiß, was er damit vergleichen würde.Wir sollten deshalb besser fragen:„Welches dieser Kundenbedürfnisse ist für uns aktuell am wichtigsten?“„Was könnten wir sonst noch bauen?“„Wie könnten wir diese Fragestellung noch angehen?“Anstatt unsere Entscheidungen als „Ja-oder-Nein“-Fragen zu formulieren, liegt der Schlüssel zu besseren Entscheidungen darin, eine „Vergleichen-und-Gegenüberstellen“-Denkweise zu entwickeln.Denn Vergleichen zwingt dein Gehirn, Unterschiede aktiv herauszuarbeiten, und genau dort entsteht bessere Urteilsqualität.Warum wir den halb leeren Becher schlechter bewerten (obwohl mehr drin ist) Warum bevorzugen Menschen manchmal objektiv schlechtere Angebote?Diese Frage wollte der Verhaltensökonom Christopher Hsee von der University of Chicago im Jahr 1998 mit einem Experiment beantworten:Eine Gruppe bewertete eine Portion Eiscreme von 200 ml in einem kleinen Becher, der dadurch überfüllt wirkte.Eine andere Gruppe bewertete 230 ml Eiscreme in einem größeren Becher, der dadurch halb leer wirkte.Das Ergebnis? Die Testpersonen waren bereit, für die 200-ml-Portion mehr zu bezahlen als für die 230-ml-Portion, obwohl diese objektiv mehr Eiscreme enthielt.Hsees Erklärung: Wenn wir isoliert entscheiden, verlassen wir uns auf Eigenschaften, die leicht zu bewerten sind (z. B. „Der Becher sieht voll aus“), und nicht auf die wichtigen Kriterien (z. B. die tatsächliche Menge).Genau das ist der Kern der Vergleichsdenkweise:Erst wenn du Optionen gegenüberstellst, siehst du, was wirklich zählt. Und du kannst bessere Entscheidungen treffen. Denn neben dem „Less-is-better“-Effekt verhindert die „Vergleichen-und-Gegenüberstellen“-Denkweise auch viele der häufigsten kognitiven Verzerrungen, die zu schlechteren Entscheidungen im Produktmanagement führen.Ankerheuristik – Die erste Idee auf dem Tisch dominiert weniger, wenn du sie aktiv gegen Alternativen abwägst, statt sie als Ausgangspunkt zu behandeln.Bestätigungsfehler – Du suchst nicht mehr nach Bestätigung für eine Entscheidung, sondern arbeitest aktiv Unterschiede zwischen Optionen heraus.Verfügbarkeitsheuristik – Alternativen werden bewusst einbezogen, statt dass nur die Ideen gewinnen, die dir gerade spontan einfallen.Werkzeuge, um die „Vergleichen-und-Gegenüberstellen“-Denkweise zu entwickeln Wie kannst du die „Vergleichen-und-Gegenüberstellen“-Denkweise konkret anwenden?Hier eine Reihe von Werkzeugen, die du im Projektmanagement nutzen kannst, die dir helfen, bessere Entscheidungen durch Vergleiche zu treffen.Werkzeug #1: Brainstorming Die meisten Brainstorming-Sessions scheitern an einem simplen Problem:Gruppendenken.Wenn Teams gemeinsam und unstrukturiert diskutieren, werden ungewohnte Vorschläge schnell kleingeredet. Es setzen sich meist nur die Ideen der lautesten oder mächtigsten Teammitglieder durch.Die Lösung? Erst mal Stille.So funktioniert strukturiertes Brainstorming:Stille Phase: Jedes Teammitglied notiert seine Ideen zunächst für sich, ohne Diskussion.Mindestzahl festlegen: Setze eine konkrete Zahl fest (z. B. mindestens 10 Ideen pro Person).Urteile verbieten: In der Sammelphase wird nicht bewertet oder diskutiert. Jede Idee wird aufgenommen.Dann erst vergleichen: Erst nachdem alle Ideen sichtbar sind, beginnt die Bewertung.Im Refinement hilft diese Methode dabei, wirklich alle Optionen auf den Tisch zu bekommen, nicht nur die erstbesten oder lautesten.Werkzeug #2: Opportunity-Solution-Tree Der Opportunity-Solution-Tree von Teresa Torres strukturiert deine Produktentscheidungen vom gewünschten Ergebnis bis zu konkreten Lösungen. Statt sofort in Features zu denken, arbeitest du dich Schritt für Schritt vor.Die Struktur:Outcome (Ziel): Was willst du erreichen? (z. B. „Nutzerengagement um 20 % steigern“)Opportunities (Chancen): Welche Kundenbedürfnisse, Schmerzpunkte oder Wünsche könnten dazu beitragen?Sub-Opportunities: Zerlege größere Opportunities in kleinere, spezifischere Probleme.Solutions (Lösungen): Erst jetzt denkst du über konkrete Features nach.Assumption-Tests: Welche Annahmen musst du testen, bevor du baust?Dieser Baum zwingt dich, mehrere Wege zu einem Ziel zu betrachten und nicht der ersten Lösung zu folgen. Er stellt somit eine Alternative zum klassischen Product-Backlog dar.Werkzeug #3: Outcome-Maps Outcome-Maps helfen dir, den Unterschied zwischen dem zu verstehen, was du tust, was andere tun und was daraus erreicht werden soll.Die vier Fragen:Goal (Ziel): Was wollen wir erreichen?Actor (Akteur): Wer muss handeln, damit das Ziel erreicht wird?Outcome (Ergebnis): Was hoffen diese Akteure zu erreichen?Feasible (Machbar): Was können wir tun, um unser Ziel zu erreichen?Du kannst nur kontrollieren, was du selbst tust, nicht das Verhalten anderer. Allerdings ist dieses Verhalten entscheidend für den Erfolg deines Produkts.Outcome-Maps machen sichtbar, was dein Team entwickelt und wie es eine Verhaltensänderung von Nutzern oder Stakeholdern hervorrufen soll.Im Produktmanagement schützt dich das davor, unrealistische Erwartungen an deine Lösung zu haben.Werkzeug #4: Produktrisiken Bevor du eine Idee umsetzt, solltest du nicht nur fragen: „Ist sie wertvoll?“, sondern auch:„Können wir sie bauen?“,„Werden Nutzer sie verstehen?“ und„Passt sie zu unserem Geschäftsmodell?“Marty Cagan identifiziert vier zentrale Risikoarten, die jedes Produktteam frühzeitig bewerten sollte.Die vier Risikodimensionen:Wertrisiko: Wird der Kunde den Mehrwert erkennen, wollen oder dafür bezahlen? Ist das Problem relevant genug? Werden Nutzer das Produkt tatsächlich verwenden oder kaufen?Verwendbarkeitsrisiko: Können Nutzer das Produkt intuitiv bedienen? Ist das User-Interface verständlich? Werden sie ihre Ziele erreichen oder stellt sich Frustration ein? Wie sieht das Onboarding aus?Umsetzbarkeitsrisiko: Haben wir die technischen Mittel, das Wissen und die Ressourcen, um das Produkt mit akzeptablem Aufwand zu bauen? Welche technischen Schulden oder Komplexitäten kommen auf uns zu? Ist die Infrastruktur vorhanden?Unternehmensrisiko: Ist das Produkt wirtschaftlich tragfähig? Passt es zum Geschäftsmodell, zu regulatorischen Rahmenbedingungen und Vertriebskanälen? Können wir es monetarisieren? Ist es skalierbar? Gibt es rechtliche oder Compliance-Hürden?Im Produktmanagement hilft dieses Framework, blinde Flecken bereits in der Planung und im Refinement von Features zu identifizieren.Werkzeug #5: Magic Estimation Softwareentwicklung in Euro zu schätzen („Dieses Feature kostet 45.000 Euro“), ist wenig vertrauenswürdig.Teams stellen jedes Feature meist nur einmal her, deshalb können Entwickler schwer einschätzen, wie viel Arbeit wirklich nötig sein wird.Besser: den relativen Aufwand unterschiedlicher Features zueinander schätzen.So funktioniert Magic Estimation:Zahlen der Fibonacci-Folge bis 21 nutzen (1, 2, 3, 5, 8, 13, 21, ?)Gemeinsam einem Backlog-Eintrag eine Größe zuordnen (Referenz)Verbleibende Einträge auf das Team verteilenJeder ordnet seine Einträge in Relation zur Referenz zu, ohne AbstimmungUnklare Einträge bekommen ein FragezeichenDas Team schaut sich die Zuordnungen an und passt sie bei Bedarf anBei großen Abweichungen: kurze DiskussionDas Resultat?Ein nach relativem Aufwand sortiertes Backlog, das eine gemeinsame Sicht des Teams auf die Komplexität widerspiegelt. Bei der Planung von Lieferterminen hilft dir das, realistischere Aussagen zu treffen.Werkzeug #6: Aufwand-Nutzen-Matrix Die Aufwand-Nutzen-Matrix klingt einfach.Jede Idee wird nach zwei Kriterien bewertet:Die Stakeholder bewerten: Wie viel Nutzen bringt sie?Die Entwickler bewerten: Wie viel Aufwand kostet sie?Dann lässt du das Team die Ideen in vier Quadranten einordnen:Hoher Nutzen, geringer Aufwand: sofort machen (Quick Wins)Hoher Nutzen, hoher Aufwand: strategisch planenGeringer Nutzen, geringer Aufwand: vielleicht späterGeringer Nutzen, hoher Aufwand: Finger wegAber die Fehler, die viele machen:Sie schätzen Aufwand und Nutzen nur im Team,sie überschätzen den Nutzen ihrer Lieblingsidee oderunterschätzen den Aufwand.Bei der Priorisierung helfen die unterschiedlichen Blickwinkel, fundiert zu entscheiden, welcher Eintrag im Product-Backlog wirklich oben stehen sollte.Werkzeug #7: Confidence-Bewertungen Bei vielen Entscheidungen im Produktmanagement ist nicht nur wichtig, was du erwartest, sondern auch, wie sicher du dir bist.Nicht alle Beweise sind gleich stark. Wenn ein paar potenzielle Kunden sagen, sie würden ein neues Feature nutzen, ist das gut. Wenn sie sich für dein Early-Adopter-Programm anmelden, ist das ein viel stärkeres Signal. Und wenn sie das Feature täglich nutzen, ist es noch stärker.Die Stärke deiner Beweise bestimmt, wie viel Vertrauen du in eine Idee haben solltest und wie viel du bereit bist, zu investieren. Confidence-Bewertungen fragen zusätzlich zur Schätzung:„Wie überzeugt bist du von dieser Einschätzung?“Die Skala (0 – 10):Hohe Confidence (7 – 10): Du hast Launch-Daten, A/B-Tests oder Nutzerstudien, die deine Annahme stützen.Mittlere Confidence (3 – 7): Du hast Kundeninterviews mit 20+ Nutzern, Usability-Studien oder ein funktionierendes MVP, aber noch keine Live-Daten.Niedrige Confidence (1 – 3): Du hast Marktdaten, Umfragen oder vielleicht haben 1 – 3 interessierte Kunden danach gefragt.Sehr niedrige Confidence (0 – 1): Du verlässt dich auf Meinungen (Team, Management, Experten) oder thematische Übereinstimmungen mit aktuellen Trends.Wenn deine Confidence niedrig ist, solltest du vor einer großen Investition testen. In der Produktentdeckung trennt dieses Werkzeug fundierte Entscheidungen von reinem Bauchgefühl deiner Stakeholder und zeigt dir, wo du mehr Beweise brauchst.Werkzeug #8: ICE-Scores ICE-Scores wurden von dem Growth-Experten Sean Ellis entwickelt und bewerten Ideen nach drei Kriterien (sie greifen Confidence-Bewertungen mit auf):Impact (Einfluss, 0 – 10): Wie viel Wert liefert die Idee an den Markt (und ans Unternehmen)?Confidence (Überzeugung, 0 – 10): Wie viele Beweise hast du, dass die Idee den erwarteten Einfluss hat?Ease (Einfachheit, 0 – 10): Wie einfach ist die Umsetzung? (1 Woche = 10, 6 Monate = 3)Die Formel: ICE-Score = Impact × Confidence × EaseEine Idee mit hohem Impact, aber niedriger Confidence oder geringer Ease rutscht im Ranking nach unten. Das schützt dich davor, auf vielversprechend klingende Ideen zu setzen, die schwer umsetzbar oder riskant sind. Im Produktmanagement hilft ICE, objektiver zu priorisieren.Werkzeug #9: Story-Maps Die Story-Map von Jeff Patton strukturiert deine Arbeit entlang der Nutzerschritte. Statt Features isoliert zu betrachten, siehst du, wie sie in den Kontext der User-Journey passen.Die drei Elemente:User-Activities (Aktivitäten): Was unternimmt ein Nutzer, um sein Ziel zu erreichen?User-Tasks (Aufgaben): Welche Details, Produktfunktionen oder Alternativen gehören zu jeder Aktivität?Releases: Welche Tasks werden zu welchem Release-Paket zusammengefasst?Der Aufbau: Horizontal ordnest du die User-Activities an, vertikal die dazugehörigen Tasks. So siehst du auf einen Blick, welche Funktionen zusammengehören und welche in welchem Release Sinn ergeben. Im Management des Product-Backlogs verhindert die Story-Map, dass du Features isoliert entwickelst, die für den Nutzer keinen Zusammenhang ergeben.Werkzeug #10: A/B-Tests 2009 veröffentlichte Microsoft die Studie „Online Experimentation at Microsoft“ mit einem ernüchternden Ergebnis:Nur ein Drittel der Ideen verbessert die Kennzahlen, für die sie entwickelt wurden.Ein Drittel liefert ein negatives Ergebnis.Ein Drittel liefert kein messbares Ergebnis.Bei Amazon lag die Erfolgsquote unter 50 %. Selbst bei Microsoft, wo 21 Experten vorhersagen sollten, welches Design gewinnen würde, lagen nur 3 richtig. Der Gewinner? Nicht das schönste Design, sondern das einfachste. Und es brachte 10 % mehr Umsatz. Ein noch drastischeres Beispiel: Eine Verzögerung von nur 400 Millisekunden bei Google führte zu 1 % weniger Suchanfragen – mehreren Hundert Millionen Dollar Verlust pro Jahr. Bei Amazon kosteten 100 Millisekunden Verzögerung 1 % Umsatz.Was lernen wir daraus für bessere Entscheidungsfindung?Die bestbezahlte Meinung im Raum liegt oft falsch. Die Daten liegen nicht oft falsch. A/B-Tests schützen dich davor, auf Annahmen zu bauen, und eignen sich perfekt für die Produktvalidierung. Du testest Ideen gegeneinander, bevor du voll investierst.In meinem Training „Professional Scrum Product Owner – AI Essentials“ ist evidenzbasiertes Entscheiden ein zentrales Thema. Was ich dort mit den Teilnehmern erarbeite, findest du hier als Playbook zum direkt Ausprobieren.KI-Playbook: Bessere Entscheidungen KI macht schlechte Priorisierung schneller sichtbar als je zuvor.Zu liefern ist nicht mehr der Flaschenhals in der Entwicklung – sondern zu entscheiden, was wertvoll genug ist, es zu liefern. Damit diese Entscheidung fundiert getroffen werden kann, solltest du Optionen vergleichen und Alternativen abwägen.Aber welches der 10 Werkzeuge passt zu deiner aktuellen Situation? Brauchst du Brainstorming für neue Ideen? ICE-Scores zur Priorisierung? Oder Produktrisiken, um blinde Flecken aufzudecken?Genau hier hilft dir das KI-Playbook.Kopiere den KI-Prompt in dein LLM (z. B. ChatGPT, Claude oder Gemini).Beschreibe, vor welcher Entscheidung du stehst.Lass dich beraten, welche Werkzeuge du nutzen könntest, damit die Entscheidung fundiert ist.Hier der Prompt zum Download.
PS: Mehr davon – live und mit KI? In meinen “Scrum mit KI“-Trainings arbeiten wir genau an diesen Themen. Hier findest du die nächsten Termine.