Feature Requests priorisieren – 5 bewährte Methoden im Vergleich

Warum überhaupt ein Framework?

Wenn drei Stakeholder mit drei verschiedenen „Top-Prioritäten" anrufen, gewinnt ohne ein Framework derjenige, der am lautesten spricht oder am hartnäckigsten bleibt. Frameworks ändern nichts daran, dass am Ende eine Entscheidung getroffen werden muss – aber sie machen die Entscheidung nachvollziehbar, verteidigbar und reproduzierbar. Wenn jemand in drei Monaten fragt „Warum haben wir Feature X nicht gebaut?", liegt die Antwort dokumentiert vor.

Im Folgenden fünf Methoden, die sich in der Praxis bewährt haben – mit den jeweiligen Stärken und Schwächen.

1. RICE – Reach, Impact, Confidence, Effort

RICE ist der etablierteste Score-Ansatz. Vier Dimensionen werden für jede Idee geschätzt und zu einer Zahl verrechnet:

• Reach: wie viele Nutzer pro Zeiteinheit profitieren? (z. B. „300 Nutzer pro Quartal")
• Impact: wie stark profitieren sie? (Skala: 3 = massiv, 2 = stark, 1 = mittel, 0.5 = klein, 0.25 = minimal)
• Confidence: wie sicher sind die Schätzungen? (z. B. 80 % = solide Daten, 50 % = Annahme)
• Effort: wie viele Person-Wochen werden gebraucht?

Der Score lautet: (Reach × Impact × Confidence) / Effort. Höher = wertvoller.

Rechenbeispiel mit drei Vorhaben:

• Dark Mode: Reach 1500, Impact 0.5, Confidence 90 %, Effort 2 → Score 337,5
• Custom Domain: Reach 200, Impact 2, Confidence 80 %, Effort 3 → Score 106,7
• Slack-Integration: Reach 500, Impact 1, Confidence 60 %, Effort 4 → Score 75

Dark Mode landet trotz geringem Einzel-Impact oben, weil es viele Nutzer mit wenig Aufwand erreicht. RICE ist gut, um „naheliegende" Quick Wins gegenüber „beeindruckenden" Großvorhaben zu verteidigen.

Schwäche: die Eingangsschätzungen sind oft unsicher. Wenn Reach und Effort jeweils ±50 % schwanken können, schwankt der Score um den Faktor 9. Ergo: RICE-Scores sind keine Wahrheit, sondern Diskussions-Anker.

2. MoSCoW – Must, Should, Could, Won't

MoSCoW kategorisiert Vorhaben in vier Buckets:

• Must: ohne das geht nichts. Kein Release.
• Should: wichtig, aber das Release ginge auch ohne.
• Could: schön, wenn Zeit übrig ist.
• Won't: bewusst nicht im Scope.

Die Disziplin: „Must" muss eng definiert sein. Wer alles als Must einstuft, hat keine Priorisierung getroffen. Eine Faustregel: in einem Quartalsplan haben maximal 30 % Anteil „Must"-Items.

Stärke: einfach zu kommunizieren. Selbst Nicht-PM-Stakeholder verstehen die Buckets sofort. Ideal für Workshops mit gemischtem Publikum.

Schwäche: keine Quantifizierung. Zwei „Must"-Items sind gleich wichtig – innerhalb des Buckets fehlt die Sortierung.

3. Impact vs. Effort – die 2×2-Matrix

Die schnellste pragmatische Methode. Eine 2×2-Matrix mit „Impact" (hoch/niedrig) auf einer Achse und „Effort" (hoch/niedrig) auf der anderen:

• Quick Wins (hoher Impact, niedriger Effort): zuerst angehen
• Big Bets (hoher Impact, hoher Effort): strategische Investitionen, aber bewusst
• Fill-ins (niedriger Impact, niedriger Effort): nur, wenn Lücken in der Sprint-Planung sind
• Time Sinks (niedriger Impact, hoher Effort): bewusst vermeiden

Stärke: in 30 Minuten anwendbar. Für die Quartals-Planung mit 20 Items eine gute Methode, um Klarheit zu schaffen.

Schwäche: zu grob für komplexe Backlogs. Bei 200 Items in derselben Quadrant brauchst du wieder eine feinere Sortierung.

4. Kano-Modell – Begeisterungsfaktoren erkennen

Das Kano-Modell ergänzt die rein quantitative Sicht um eine emotionale. Es unterscheidet drei Feature-Typen:

• Basis-Features: werden vorausgesetzt. Sind sie da, freut sich niemand. Fehlen sie, ist die Frustration groß. Beispiel: Login funktioniert.
• Leistungs-Features: je mehr, desto besser. Geschwindigkeit, Genauigkeit, Verfügbarkeit. Werden direkt mit Wettbewerbern verglichen.
• Begeisterungs-Features: niemand erwartet sie. Wenn sie da sind, lieben Nutzer das Produkt. Beispiel: ein eleganter Empty-State, eine charmante Animation.

Die Investitionslogik: Basis-Features sind Pflicht (Wegfall = Risiko), Leistungs-Features lohnen kontinuierliche Verbesserung, Begeisterungs-Features sind die strategische Differenzierung.

Stärke: macht sichtbar, warum manche Features trotz hoher RICE-Scores enttäuschen (sie sind Basis-Features – ihr Vorhandensein wird vorausgesetzt).

Schwäche: schwer zu quantifizieren. Eher ein Denk-Modell als ein Score.

5. Voting als demokratische Methode

In öffentlichen Feedback-Boards oder bei großer Nutzerbasis wird Voting eingesetzt. Jeder Anwender kann pro Vorschlag eine Stimme abgeben, die Liste wird automatisch nach Stimmen sortiert.

Stärke: skaliert. 1000 Stimmen sind ein deutlich belastbareres Reach-Signal als drei Customer-Interviews.

Schwäche: Power-User-Bias. Laute, technikaffine Nutzer stimmen überproportional ab. Wenn die Top-Voted-Vorschläge alle aus dem gleichen Segment stammen, ist Misstrauen geboten.

Praxis-Tipp: Voting als ein Signal unter mehreren verwenden. Es ersetzt nicht die Priorisierung, es liefert nur Reach-Daten für RICE oder MoSCoW.

Welche Methode wann?

Die Realität: kein Team nutzt nur eine Methode. Typische Kombinationen:

• Kleines Team, frühe Phase: Impact vs. Effort wöchentlich. Wenn das Backlog wächst, RICE einführen.
• Mid-Size, fester Quartalsplan: MoSCoW mit Stakeholdern, RICE intern für die Reihenfolge.
• Großes Produkt mit Community: Voting im Feedback Board als Reach-Signal, RICE oder ICE intern, MoSCoW für die Kommunikation mit Sales.

Mehr Hintergrund zu RICE und MoSCoW findest du im Glossar-Eintrag Priorisierungsframework.

Fazit

Frameworks lösen keine Priorisierung. Sie machen sie verteidigbar. Wer mit drei Lautstärken konfrontiert ist und sich auf ein Framework einigen kann, hat schon den ersten Schritt geschafft – die Diskussion verschiebt sich auf die Annahmen (Reach, Effort, Impact), nicht mehr auf die persönliche Meinung.

Wenn dein Team noch keinen einheitlichen Ansatz hat, fang mit Impact vs. Effort an. Es kostet 30 Minuten Setup, liefert sofort Klarheit, und du kannst später zu RICE wechseln, wenn das Backlog größer wird.

Wenn du Feature Requests strukturiert sammeln und gleich mit Voting-Daten anreichern möchtest, kannst du das mit einem Feature-Request-Tool in 10 Minuten aufsetzen.