Um Feature-Wünsche zu priorisieren, gruppierst du sie nach dem Problem dahinter, bewertest jedes Problem nach Reichweite, Leidensdruck, Passung und Aufwand und sprichst mit ein paar der Leute, die gefragt haben, bevor du dich festlegst. Diesen letzten Schritt überspringen die meisten Teams, dabei kannst du eine schlechte Wette nirgends günstiger erkennen. Das Falsche zu bauen ist weit verbreitet: Pendos Feature Adoption Report 2019, der auf drei Monaten Nutzungsdaten aus 615 Abos von Pendo-Kunden beruht, ergab, dass 80 Prozent der Funktionen in einem durchschnittlichen Softwareprodukt selten oder nie genutzt werden.
Das Wichtigste in Kürze
- Ein Feature-Wunsch ist die Vermutung eines Kunden, wie eine Lösung aussehen könnte. Priorisiere das Problem dahinter.
- Stimmenzahlen zeigen, wer sich gemeldet hat, nicht wie sehr das Problem schmerzt.
- Nimm irgendein einfaches Framework, aber füttere es mit dem, was du in Gesprächen mit den Fragenden lernst.
- Entscheide, und sag den Leuten dann, wie du entschieden hast, auch wenn es ein Nein ist.
Warum Stimmenzahlen in die Irre führen
Die meisten Teams sammeln Wünsche irgendwo: auf einem Board, in einer Tabelle, in einem Slack-Channel. Dann bauen sie, was die meisten Stimmen hat. Das fühlt sich fair an, ist aber riskant.
- Laute Kunden werden gezählt, leise nicht. Die Leute, die Wünsche posten, sind nicht immer die, die du am liebsten halten willst.
- Wünsche sind Lösungen, keine Probleme. „Baut einen CSV-Export ein“ kann in Wahrheit heißen: „Meine Chefin will einen wöchentlichen Bericht.“ Eine geplante Zusammenfassung per E-Mail könnte das besser lösen.
- Duplikate teilen die Stimmen auf. Fünf Wünsche, fünfmal anders formuliert, sehen aus wie fünf kleine Probleme statt wie ein großes.
- Stimmen haben kein Gewicht. Ein Wunsch, der einen großen Kunden halten würde, zählt genauso viel wie ein Nice-to-have.
- Stimmen verfallen nicht. Alte Wünsche stehen ganz oben, lange nachdem der Bedarf verschwunden ist.
Eine Stimme ist ein Signal, nachzufragen. Sie ist nicht die Antwort.
Die Priorisierungs-Frameworks im Kurzüberblick
In jedem Ratgeber begegnen dir dieselben paar Frameworks. Hier siehst du, wofür jedes gut ist.
| Framework | So funktioniert es | Ideal für | Achte auf |
|---|---|---|---|
| Stimmenzahl | Nach Anzahl der Wünsche sortieren | Ein erstes Signal | Laute Kunden, aufgeteilte Duplikate |
| RICE | Reach × Impact × Confidence ÷ Effort | Viele Ideen vergleichen | Confidence ist oft geraten |
| ICE | Impact × Confidence × Ease | Schnelle Vorsortierung | Sehr subjektiv |
| MoSCoW | Must, Should, Could, Won’t | Eine feste Deadline oder ein Release | Keine Reihenfolge innerhalb der Gruppen |
| Impact vs. Aufwand | Eine einfache 2×2-Matrix | Quick Wins erkennen | Ignoriert, wie viele Leute betroffen sind |
| Kano | Basis-, Leistungs- und Begeisterungsmerkmale | Erwartungen verstehen | Braucht für saubere Ergebnisse eine Umfrage |
| Umsatzgewichtung | Jede Stimme nach Kundenwert gewichten | B2B mit wenigen großen Kunden | Kann wenige große Kunden überbedienen |
RICE, zuerst beschrieben von Sean McBride bei Intercom, ist für die meisten Produktteams ein vernünftiger Standard. Aber jedes Framework hat dieselbe Schwachstelle: Reach, Impact und Confidence hängen alle davon ab, wie gut du das Problem verstehst. Die Schritte unten helfen dir, genau diesen Teil richtig zu machen.
Schritt 1: Sammle alle Wünsche an einem Ort
Wünsche kommen aus Support-Tickets, Sales-Calls, In-App-Nachrichten, E-Mails und Bewertungen. Trag sie in eine Liste ein, damit du sie nebeneinander sehen kannst.
Halte für jeden Wunsch fest:
| Feld | Beispiel |
|---|---|
| Wunsch | Berichte als CSV exportieren |
| Wer gefragt hat | Ops-Leiterin bei einem mittelgroßen Kunden |
| Genauer Wortlaut | „Ich kopiere jeden Montag Zahlen für meinen Chef in eine Tabelle.“ |
| Tarif oder Segment | Business-Tarif, 40 Plätze |
| Quelle und Datum | Support-Ticket, 3. März |
Der genaue Wortlaut ist am wichtigsten. Er zeigt das Problem oft klarer als der Wunsch selbst.
Vergiss die leisen Quellen nicht. Notizen zu verlorenen Deals und Antworten von Kunden, die gekündigt haben, enthalten oft Wünsche, die nie auf deinem Board landen.
Schritt 2: Finde das Problem hinter jedem Wunsch
Formuliere jeden Wunsch als Problem, in einem einfachen Satz:
Wer will Ziel erreichen, aber Hindernis.
Für das CSV-Beispiel: „Teamleads wollen ihrer Führungskraft die Zahlen der Woche zeigen, aber sie müssen sie von Hand abtippen.“
Gruppiere jetzt Wünsche, die dasselbe Problem teilen. Fünf verschiedene Wünsche (CSV-Export, geplante E-Mails, ein öffentlicher Dashboard-Link, ein PDF-Button und ein API-Endpunkt) können alle dasselbe Problem sein. Zusammen ist es viel größer, als jeder einzelne Wunsch aussah.
Das ist die Kernidee hinter Jobs to be Done: Leute wollen nicht die Funktion selbst. Sie wollen den Fortschritt, den sie ihnen bringt.
Schritt 3: Sprich mit den Leuten, die gefragt haben
Bevor du irgendetwas bewertest, sprich mit ein paar Leuten hinter deinen größten Gruppen. Ein kurzes Gespräch verrät dir mehr als ein Haufen Stimmen.
Frag nach ihrer echten Situation, nicht nach deiner Idee:
- „Was wolltest du gerade tun, als du dir das gewünscht hast?“
- „Wie löst du das heute?“
- „Wie oft kommt das vor?“
- „Was passiert, wenn es nicht erledigt wird?“
- „Wer ist noch betroffen?“
Vermeide „Würdest du das nutzen, wenn wir es bauen?“ Fast alle sagen Ja, also erfährst du nichts. Unser Ratgeber zu Suggestivfragen zeigt weitere Beispiele, die du vermeiden solltest.
So klingt ein gutes Gespräch
Du: Was wolltest du gerade tun, als du dir den CSV-Export gewünscht hast?
Kunde: Unsere Zahlen in den Montagsbericht bringen.
Du: Wer liest den Bericht?
Kunde: Meine Chefin. Sie will nur drei Zahlen und den Trend. Ich kopiere sie jede Woche in Folien.
Du: Wie lange dauert das?
Kunde: Fast eine Stunde, jeden Montag.
Der Wunsch war „CSV-Export“. Der Bedarf ist „meiner Chefin jede Woche drei Zahlen zeigen, ohne den Kleinkram“. Eine geplante Zusammenfassung per E-Mail könnte das in einem Bruchteil der Entwicklungszeit lösen, und sie würde jedem Kunden mit demselben Montagsritual helfen.
Starke und schwache Belege
| Schwaches Signal | Starkes Signal |
|---|---|
| „Wäre schön zu haben.“ | „Ich verbringe jeden Montag eine Stunde damit.“ |
| „Klar, würde ich nutzen.“ | „Wir zahlen nur dafür für ein anderes Tool.“ |
| Ein einzelner Upvote | Ein Workaround, den sie selbst gebaut haben |
| „Das wollen doch alle.“ | Namen, Daten und was es sie gekostet hat |
Wie viele Gespräche reichen
Sprich weiter, bis du vorhersagen kannst, was die nächste Person sagt. Wenn sich die Geschichten wiederholen, verstehst du das Problem gut genug, um es zu bewerten.
Wenn sich die Geschichten ständig ändern, ist das auch ein Ergebnis. Ein Wunsch kann mehrere verschiedene Probleme abdecken, und dann solltest du die Gruppe aufteilen. Weitere Fragen findest du in unseren Fragen für Kundeninterviews.
Schritt 4: Bewerte jedes Problem
Bewerte jetzt die Probleme, nicht die Wünsche. Halte es einfach. Eine Bewertung, die dein Team wirklich aktualisiert, schlägt eine perfekte, die niemand anfasst.
Bewerte jedes Problem von 1 bis 3 in vier Punkten:
- Reichweite: wie viele der Kunden, die dir wichtig sind, dieses Problem haben.
- Leidensdruck: wie sehr es ihnen wehtut, nach dem, was du gehört hast.
- Passung: wie gut die Lösung dazu passt, wohin sich dein Produkt entwickelt.
- Aufwand: wie viel Arbeit es macht. Höher heißt mehr Arbeit.
Dann rechnest du: Reichweite × Leidensdruck × Passung ÷ Aufwand.
| Problem | Reichweite | Leidensdruck | Passung | Aufwand | Score |
|---|---|---|---|---|---|
| Wöchentliche Zahlen mit Führungskräften teilen | 3 | 2 | 3 | 2 | 9 |
| Single Sign-on für größere Teams | 1 | 3 | 3 | 3 | 3 |
| Dark Mode | 2 | 1 | 1 | 2 | 1 |
Das Teilen-Problem gewinnt, auch wenn der Dark Mode für sich allein mehr Stimmen hatte. Die Wünsche zum Teilen waren über fünf verschiedene Funktionsideen verstreut, deshalb wirkte keine davon groß.
Gewichte nach Umsatz, aber vorsichtig
Im B2B ist es fair, Problemen mehr Gewicht zu geben, die deine größten oder am schnellsten wachsenden Kunden betreffen. Lass die Umsatzgewichtung nur nicht die Roadmap bestimmen. Ein paar große Kunden können dich zu Funktionen ziehen, die sonst niemand braucht, und neue Segmente, die du gewinnen willst, bringen noch keinen Umsatz.
Wenn ein großer Kunde fragt
Manchmal will ein großer Kunde etwas, das sonst niemand gewünscht hat. Es ist verlockend, sofort Ja zu sagen.
Finde zuerst das Problem dahinter, wie bei jedem anderen Wunsch. Frag dich dann, ob kleinere, ähnliche Kunden beim Wachsen auf dasselbe Problem stoßen werden. Wenn ja, gehört es vielleicht auf die Roadmap. Wenn es nur zu diesem einen Kunden passt, behandle es als individuellen Deal mit klarem Preis und Zeitplan.
Lass Platz für eigene Wetten
Kundenwünsche zeigen dir die Probleme von heute. Wohin sich der Markt bewegt, zeigen sie selten. Leg vorab fest, wie viel Zeit deines Teams in Kundenprobleme fließt, wie viel in eigene strategische Wetten und wie viel in Fehlerbehebung und Wartung. Priorisiere Wünsche dann innerhalb ihres Anteils, damit ein volles Board nicht still und leise die ganze Roadmap übernimmt.
Schritt 5: Entscheide und gib Rückmeldung
Nimm das wichtigste Problem, wähl eine Lösung und sag den Leuten, die gefragt haben, Bescheid. Kunden, die eine Antwort bekommen, sagen dir auch weiterhin, was sie brauchen. Unser Ratgeber zum Kundenfeedback-Kreislauf zeigt, wie daraus eine Gewohnheit wird.
Nein zu sagen gehört dazu. Zwei Vorlagen, die du anpassen kannst:
Nicht jetzt
Hallo Name,
danke für deine Anfrage zu Funktion. Wir bauen sie in diesem Quartal nicht.
Wir kümmern uns zuerst um anderes Problem, weil mehr unserer Kunden darauf stoßen.
Du hast erwähnt, dass du Ziel der Person willst. Bis dahin lösen
manche Kunden das so: Workaround oder Hilfeartikel.
Ich habe deine Nachricht mit deinen genauen Worten aufgehoben und sage dir Bescheid, wenn sich daran etwas ändert.
Nicht geplant
Hallo Name,
danke für deine Idee zu Funktion. Ich will ehrlich zu dir sein:
Sie passt nicht zu der Richtung, in die wir Produkt entwickeln, deshalb planen wir sie nicht.
Für Ziel der Person passt anderes Tool oder Workaround vielleicht besser.
Wenn sich dein Bedarf ändert, würde ich trotzdem gern davon hören.
Ein einfacher Rhythmus, der die Liste ehrlich hält
Einmal zu priorisieren hilft wenig. Eine leichte Routine hilft viel.
| Wie oft | Was du tust |
|---|---|
| Wöchentlich | Neue Wünsche mit genauem Wortlaut eintragen, Duplikate zusammenführen, jeden Wunsch einem Problem zuordnen |
| Monatlich | Mit drei bis fünf Leuten hinter deinen größten Problemgruppen sprechen |
| Vierteljährlich | Die Liste neu bewerten, das Nächste auswählen und den Fragenden sagen, wie du entschieden hast |
Zwanzig Minuten pro Woche reichen für die meisten Teams. Die monatlichen Gespräche sorgen dafür, dass deine Bewertungen an echten Kunden hängen und nicht an dem, wer zuletzt etwas gepostet hat.
Fehler, die du beim Priorisieren von Feature-Wünschen vermeiden solltest
- Für den lautesten Kunden bauen. Prüf zuerst, ob andere das Problem teilen.
- Funktionen statt Probleme bewerten. Dann zerlegst du ein großes Problem in kleine Wünsche, die alle unbedeutend wirken.
- Fragen, ob Leute es nutzen würden. Frag, wie sie das Problem heute lösen.
- Nie zurückschauen. Bewerte deine Liste jedes Quartal neu. Der Bedarf ändert sich, und dein Produkt auch.
So hilft dir Diaform
Mit allen hinter einem Wunsch zu sprechen kostet Zeit, und die meisten buchen keinen Termin. Mit Diaform verschickst du stattdessen einen Link. Ein KI-Agent stellt deine Fragen per Sprache oder Text, hakt nach, wenn jemand „wäre schön zu haben“ sagt, und fasst jedes Gespräch zusammen, sobald es endet.
Verschick den Link per E-Mail oder zeig ihn in deiner App. Ab dem Pro-Tarif können Links nur für Eingeladene die E-Mail-Adresse oder Nutzer-ID jeder Person mitgeben, damit du weißt, welcher Kunde was gesagt hat. Exportiere die Antworten als CSV und füge sie deiner Bewertungstabelle hinzu. Sieh dir an, wie Diaform mit Produktfeedback umgeht, oder starte eine kostenlose 14-tägige Testphase.
