Roadmap-Priorisierung: RICE vs. Kano vs. Opportunity Solution Tree

Ich habe erlebt, wie sich ein Team per RICE-Score in ein Jahr toter Features manövriert hat. Fünfzehn Punkte, alle sorgfältig eingestuft, alle pünktlich geliefert. Aktivierung bewegte sich nicht. Kundenbindung bewegte sich nicht. Der Umsatz pro Account blieb konstant. Der CEO stellte schließlich die Frage, die jeder PM fürchtet: „Was haben wir eigentlich gelernt?" Niemand hatte eine gute Antwort, weil das Framework nie auf Lernen ausgerichtet war. Es diente der Verteidigung einer Reihenfolge.

Das ist das Problem mit Priorisierungs-Frameworks. Die meisten PMs verwenden RICE, weil Intercom es 2017 bloggte und es sich wie ein Virus durch jede Produkt-Organisation mit einem Notion-Abo verbreitete. Es wirkt rigoros. Es erzeugt eine Zahl. Stakeholder nicken, wenn sie die Tabelle sehen. Aber das Framework ist nicht die Antwort auf Ihr Roadmap-Problem. Das Framework ist ein Katalysator für das Gespräch, das Ihr Team vermeidet. Wählen Sie dasjenige, das das richtige Gespräch erzwingt, und Sie liefern besser. Wählen Sie das falsche, und Sie liefern viel.

Sprechen wir also über die drei, die Sie tatsächlich verteidigen müssen, was jedes davon leistet, wo jedes versagt und wann Sie sie kombinieren sollten.

RICE-Mathematik mit echten Zahlen

RICE steht für Reach, Impact, Confidence, Effort. Die Formel ist unkompliziert:

Score = (Reach x Impact x Confidence) / Effort

• Reach: wie viele Nutzer dies in einem bestimmten Zeitraum betrifft. Normalerweise monatlich. Seien Sie ehrlich, was „betrifft" bedeutet.
• Impact: wie stark es Ihre Zielkennzahl pro betroffenen Nutzer bewegt. Das ursprüngliche Intercom-Raster verwendet 3 / 2 / 1 / 0,5 / 0,25 für massiv / hoch / mittel / niedrig / minimal. Es ist absichtlich grob.
• Confidence: ein Prozentsatz. 100% bedeutet, Sie haben Daten. 80% bedeutet, Sie haben Belege. 50% bedeutet, Sie raten.
• Effort: Person-Monate über Produkt, Design und Engineering kombiniert.

Ein echtes Beispiel. Stellen Sie sich ein B2B SaaS mit 4.000 monatlich aktiven Accounts vor, und Sie bewerten drei Roadmap-Kandidaten für das nächste Quartal:

Bulk-Import gewinnt mit deutlichem Abstand. Und ehrlich gesagt sollte er das bei diesem Scoring. Sie haben hohe Confidence, ordentliche Reichweite und geringen Aufwand. RICE tut genau das, wofür es gebaut wurde: die offensichtliche, günstige und wirksame Wette ans Licht bringen.

Wann RICE wirklich funktioniert:

• Reife Produkte mit klaren KPIs. Sie wissen, wie Aktivierung, Kundenbindung und Konversion aussehen. Sie können Impact in einem vernünftigen Rahmen vorhersagen.
• Große Teams, die parallel liefern. Wenn fünf Squads die Sequenzierung koordinieren müssen, ist ein gemeinsames Scoring-Raster schneller als zehn Meetings.
• Abwägungen gegenüber finanzorientierten Führungskräften verteidigen. Ein CFO kann eine RICE-Tabelle lesen. Eine Customer Journey Map kann er nicht lesen.

Wo RICE versagt:

• Frühe Produkte. Reach ist eine Schätzung, weil Sie Ihr echtes Publikum noch nicht kennen. Impact ist Wunschdenken, weil Sie nicht wissen, wie Erfolg aussieht.
• Discovery-Phase-Wetten. RICE bestraft Unsicherheit durch den Confidence-Multiplikator, was bedeutet, dass wirklich Neues von allem Inkrementellen verdrängt wird. Ihre Roadmap füllt sich mit Bulk-Import-Features und nie mit der Wette, die die Kurve tatsächlich verändern könnte.
• Strategische Wetten. „Sollten wir in den Mid-Market expandieren?" passt nicht in eine RICE-Tabelle. Versuchen Sie es nicht.

Die ehrliche Kritik: RICE optimiert für das Messbare, nicht für das Wichtige. Verwenden Sie es, wo Messung einfach ist, ignorieren Sie es, wo sie es nicht ist.

Das Kano-Modell mit einer Umfragefrage, die wirklich funktioniert

Das Kano-Modell ist älter und eigentümlicher als RICE. Noriaki Kano entwickelte es in den 1980er Jahren, um zu erklären, warum Kunden manche Features lieben und andere kaum bemerken. Es gibt fünf Kategorien, aber für die Priorisierung brauchen Sie nur drei:

• Basic (Muss vorhanden sein): Kunden bemerken es nicht, wenn es da ist, aber sind wütend, wenn es fehlt. Zwei-Faktor-Authentifizierung. Export nach CSV. Anständige Suche. Das Vorhandensein dieser Features erzeugt keine Begeisterung. Das Fehlen treibt Kunden weg.
• Performance (Mehr ist besser): lineare Zufriedenheit. Schnellere Seitenladezeiten, mehr Integrationen, bessere Verfügbarkeit. Investieren Sie proportional zu den Kosten.
• Excitement (Begeisterer): Kunden erwarten es nicht, können es nicht beschreiben, aber lieben es, wenn sie es bekommen. Das, was die Demo zum Abschluss bringt. Slack-Threads, Linears Tastaturkürzel, Figmas Multiplayer-Cursor bei ihrer Einführung.

Die anderen zwei Kategorien (Indifferent und Reverse) sind der Bereich, in dem Sie Features streichen. Indifferent bedeutet, niemanden kümmert es. Reverse bedeutet, manche lehnen es aktiv ab (z.B. aggressive KI-Vorschläge in einem ruhigen Produktivitäts-Tool).

Hier ist die Umfragefragen-Vorlage, die ich tatsächlich verwende, zwei Fragen pro Feature:

1. Wie würden Sie sich fühlen, wenn das Produkt dieses Feature hätte?
2. Wie würden Sie sich fühlen, wenn das Produkt dieses Feature nicht hätte?

Beide auf einer 5-Punkte-Skala beantwortet: Ich mag es / Ich erwarte es / Ich bin neutral / Ich toleriere es / Ich mag es nicht.

Die Kreuzauswertung sagt Ihnen die Kategorie. „Mag es / mag es nicht, es nicht zu haben" = Performance. „Neutral / mag es nicht, es nicht zu haben" = Basic. „Mag es / neutral über das Fehlen" = Excitement. Führen Sie das mit 50-100 Kunden pro Segment durch, und Sie haben Signal, das es wert ist, verteidigt zu werden.

Wann Kano gewinnt:

• Entscheidungen über Feature-Parität. „Wettbewerber X hat gerade Y herausgebracht. Brauchen wir es?" Kano sagt Ihnen, ob Y Basic (ja, sofort liefern), Performance (ja, aber im Zeitplan) oder Excitement (nur wenn es differenziert) ist.
• Scope reduzieren. Wenn Engineering Ihnen sagt, die Spec braucht sechs Wochen und Sie haben vier, sagt Kano Ihnen, was Sie streichen. Excitement zuerst streichen, wenn Basics noch nicht fertig sind.
• „Sollen wir das überhaupt bauen?"-Entscheidungen. Wenn ein Feature als Indifferent bewertet wird, sagen die Daten Ihnen, es aufzugeben.

Die Falle: Kano braucht echte Kundendaten, nicht die Intuition des PM. Ich habe ganze Roadmaps gesehen, die durch eine Kano-Analyse gerechtfertigt wurden, bei der drei Personen in einem Konferenzraum darüber diskutierten, in welche Spalte Bulk-Delete gehört. Das ist kein Kano. Das ist ein PM, der Meinungen durch einen Framework-Namen zu legitimieren versucht.

Opportunity Solution Tree: wann er gewinnt

Teresa Torres entwickelte den Opportunity Solution Tree (OST) für Teams, die kontinuierliche Discovery betreiben. Die Struktur:

                  Outcome
                     |
       -----------------------------
       |             |             |
  Opportunity   Opportunity   Opportunity
       |             |             |
   ---------     ---------     ---------
   |       |     |       |     |       |
 Solution Solution Solution ... Solution
   |
Experiment

Sie beginnen mit einem Outcome (einem messbaren Geschäftsergebnis, z.B. „Trial-to-Paid-Konversion um 15% steigern"). Sie erfassen Opportunities (Kundenschmerzen, unerfüllte Bedürfnisse, Reibungsmomente) aus wöchentlichen Kundeninterviews. Unter jeder Opportunity brainstormen Sie mehrere Lösungen. Unter jeder vielversprechenden Lösung entwerfen Sie ein Experiment zur Validierung, bevor Sie bauen.

Das Geniale daran ist die erzwungene Hierarchie. Sie können keine Lösung gegen eine andere Lösung priorisieren. Sie können nur Opportunities priorisieren und dann die beste Lösung für die gewählte Opportunity auswählen.

Wann OST gewinnt:

• Kontinuierliche Discovery-Teams. Teams, die wöchentliche Kundenkontaktpunkte führen und Prototypen-Tests durchführen. Der Baum aktualisiert sich, wenn die Discovery neue Opportunities aufdeckt.
• Outcome-getriebene Organisationen. Wo das Leadership Ziele als Outcomes setzt, nicht als Feature-Listen. OST übersetzt Outcomes in eine Discovery-und-Build-Pipeline.
• Feature-Fabrik-Modus vermeiden. OSTs entscheidender Schritt ist, sichtbar zu machen, wenn eine Lösung nicht auf eine Opportunity einzahlt, die auf den Outcome einzahlt. Wenn keine Verbindung besteht, nicht bauen.

Wo OST versagt:

• Organisationen, wo „Discovery" ein Nutzerinterview pro Quartal bedeutet. OST ist ein Betriebssystem für kontinuierliche Discovery. Ohne den Discovery-Rhythmus ist der Baum dekorativ. Sie füllen ihn mit Opportunities, die Sie angenommen haben statt gefunden haben.
• Teams ohne Research-Zugang. Wenn Ihr PM um fünf Kundengespräche pro Monat kämpfen muss, ist OST ein Wunsch, keine Realität.
• Reine Ausführungsquartale. Manchmal müssen Sie das verlängerungsblockierende Element liefern. OST hilft nicht dabei, acht bekannte Features zu sequenzieren.

„Jetzt, als nächstes, später" und warum das RICE im Trenchcoat ist

Die meisten „Jetzt / Als nächstes / Später"-Roadmaps sind RICE-Rankings mit versteckten Zahlen. Der PM hat alles bewertet, die Spitze der Liste kam in „Jetzt", die Mitte in „Als nächstes", das Ende in „Später". Das Format gibt vor, flexibel zu sein, aber die Priorisierung ist identisch mit einer sortierten Tabelle.

Das Format bedeutet tatsächlich etwas, wenn jeder Bereich einen anderen epistemischen Standard hat:

• Jetzt: hohe Confidence, abgegrenzt, committed. Sie werden das liefern. Das Team verantwortet den Outcome.
• Als nächstes: mittlere Confidence, Problem validiert, Lösung noch in der Discovery. Sie glauben, dass das wichtig ist. Sie haben noch nicht bewiesen, dass die Lösung funktioniert.
• Später: Opportunities, keine Lösungen. Dinge, die Sie von Kunden gehört haben, die noch keinen Slot verdient haben.

Wenn Ihr „Später"-Bereich Feature-Namen mit Aufwandsschätzungen enthält, machen Sie RICE im Trenchcoat. Wenn Ihr „Später"-Bereich Kundenprobleme mit offenen Fragen enthält, machen Sie es richtig.

Confidence: der Input, den niemand ehrlich bewertet

Jeder PM, den ich je getroffen habe, inflationiert Confidence bei seinem Lieblings-Feature. Die Person, die die Confidence-Spalte des Frameworks als Kalibrierungsinstrument entworfen hat, erlebt, wie sie zur Bauchgefühl-Spalte wird.

Die Lösung: ein Confidence-Raster, das an Belege gebunden ist, nicht an Gefühle.

Alles unter 60% sollte unter keinem Framework in Ihrer „Jetzt"-Spalte sein. Alles unter 40% sollte eine Opportunity in Ihrem OST sein, kein Feature auf Ihrer Roadmap. Wenn Sie bei etwas, das seit zwei Quartalen auf der Roadmap steht, nicht auf 60% Confidence kommen, streichen Sie es. Die Kosten, es stehen zu lassen, sind der Anschein von Fortschritt ohne echten Fortschritt.

Warum Ihre Stakeholder RICE hassen

Das ist das Diagnosegespräch, das ich mit jedem Team führe, das sagt: „RICE funktioniert bei uns nicht." Es ist fast nie das Framework. Es ist die Übersetzungsebene.

Sales hasst RICE, weil Kundenanfragen bei Reach niedrig abschneiden. Sales bringt Ihnen die deal-blockierende Anfrage des Prospects, der 80.000 USD zahlt. Reach für diesen Kunden ist eins. Der RICE-Score ist ein Bruchteil. Sales liest das als: „PM kümmert sich nicht um Umsatz." Lösung: Deal-blockierende Anfragen vollständig aus RICE herausnehmen. Eine separate „Deal-Blocker"-Spur pflegen, die nach Win-Rate-Impact bemessen ist. Sales mitteilen, dass diese Spur existiert.

CS hasst RICE, weil Bindungs-Wetten bei Impact niedrig abschneiden. Bindungs-Features zeigen selten kurzfristige Kennzahlen-Bewegungen. Sie verhindern Abwanderung, die sechs Monate später eintreten würde. RICE-Impact ist zukunftsgerichtet, aber die meisten PMs bewerten ihn quartalsübergreifend. Lösung: Bindungs-Wetten separat führen und Impact als annualisierte Abwanderungsraten-Bewegung bewerten, nicht als quartalsweise Aktivierung.

Engineering hasst RICE, weil Effort Ihre Schätzung ist, nicht ihre. PMs schätzen Aufwand anhand ähnlicher vergangener Features. Engineering weiß, dass die Codebasis drei Unwägbarkeiten hat. Lösung: Veröffentlichen Sie nie einen RICE-Score mit Ihrer eigenen Effort-Zahl. Verwenden Sie Spannen (1-2 PM-Monate, 3-5 PM-Monate, 6+) und lassen Sie Engineering diese nach einem kurzen Scoping-Durchlauf verfeinern. Der PM verantwortet Reach, Impact, Confidence. Engineering verantwortet Effort.

Das Muster: RICE liefert eine Zahl, aber die vier Inputs kommen von vier verschiedenen Stakeholdern. Wenn Sie einen einzelnen Score veröffentlichen und nicht zeigen, wie Sie gerechnet haben, liest jeder Stakeholder den Input, der ihm wichtig ist, und ist anderer Meinung. Zeigen Sie die Inputs. Diskutieren Sie Reach mit Marketing, Impact mit dem Data-Team, Confidence mit Research, Effort mit Engineering. Der Score ist das Ergebnis dieser vier Gespräche, kein Ersatz für sie.

Wann man alle drei kombiniert

Hier ist der Stack, den ich tatsächlich verwende:

1. OST nutzen, um die richtige Opportunity zu finden. Outcomes durch kontinuierliche Discovery auf Kundenchancen abbilden. Die Opportunity wählen, die die stärksten Belege und das höchste Potential für den Outcome-Impact hat. Diese Ebene überspringen, wenn Sie das Problem bereits in- und auswendig kennen (reife Features, gut verstandene Domain). Nicht überspringen, wenn Ihr Team Features liefert, die niemand angefragt hat.

2. Kano nutzen, um die Lösung zu klassifizieren. Sobald Sie eine Opportunity gewählt haben und zwei oder drei Lösungskandidaten haben, Kano auf die Kandidaten mit echten Kundendaten anwenden. Diese Ebene überspringen, wenn die Lösung offensichtlich Basic ist (Auth, Export, Barrierefreiheit). Nicht überspringen, wenn Sie zwischen „vorhandenes Feature schneller machen" und „einen Begeisterungsmoment hinzufügen" wählen und nicht sagen können, was Kunden tatsächlich wertschätzen werden.

3. RICE nutzen, um den Build zu sequenzieren. Sobald Sie entschieden haben, welche Opportunities und Lösungen Sie bauen, sequenziert RICE sie über das Quartal. Aufwand, Abhängigkeiten, Kapazität. RICE ist ein Sequenzierungs-Tool, kein Discovery-Tool. Darin verdient es seinen Platz.

Der vollständige Stack ist für die meisten Teams die meiste Zeit übertrieben. Ein Team, das inkrementelle Verbesserungen an einem reifen CRM liefert, braucht nicht jedes Quartal OST, sondern RICE auf einem sauberen backlog. Ein Pre-Product-Market-Fit-Startup braucht kein RICE, sondern OST und die Bereitschaft, die Hälfte der Roadmap wegzuwerfen. Passen Sie die Framework-Tiefe an die tatsächliche epistemische Situation an. OST auf ein Team ohne Research-Zugang zu zwingen ist Theater. RICE auf ein Team zu zwingen, das seine KPIs nicht kennt, ist Präzision ohne Genauigkeit.

Das Framework ist nicht die Antwort. Wählen Sie dasjenige, das das Gespräch erzwingt, das Ihr Team vermeidet. Meidet Ihr Team den Kundenkontakt, setzen Sie OST ein. Meidet Ihr Team das Scope-Kürzen, setzen Sie Kano ein. Meidet Ihr Team Sequenzierungs-Abwägungen, setzen Sie RICE ein. Und wenn Ihr Team alle drei meidet, liegt das Problem nicht am Framework. Das Problem ist, dass niemand eine echte Entscheidung treffen will, und keine Tabelle wird das lösen.

Mehr erfahren

• Product-Manager-Stellenbeschreibung (Begleiter)
• Kontinuierliche Discovery-Gewohnheiten für PMs
• PRDs schreiben, die Engineers nicht hassen
• Quartalsplanung mit Engineering + Design