Kurz gesagt: Wer zwanzig Features einzeln nach ihrer Wichtigkeit abfragt, bekommt zwanzig Mal „wichtig“. MaxDiff zwingt zur Entscheidung: In jedem Auswahlset wählen die Befragten das wichtigste und das unwichtigste Feature, und aus den Sets entsteht eine Rangfolge mit echten Abständen, je Plan und Rolle. Dieser Beitrag beschreibt die vier Designregeln, die Stichprobe, die Auswertung und den Weg der Rangfolge in die Roadmap-Runde.
Direkt zur Vorlage: MaxDiff Feature-Priorisierung als Online-Vorlage mit Auswahlsets im Fragebogen. Wann MaxDiff und wann Conjoint die richtige Methode ist, steht im Beitrag MaxDiff vs. Conjoint; das Ergebnis eines echten Experiments zeigt die Galerie.
Warum Wichtigkeitsskalen keine Roadmap ergeben
Die Feature-Umfrage vor dem Quartalsplanning sieht in den meisten Produktteams gleich aus: eine Liste von Features, je Feature eine Skala von „unwichtig“ bis „sehr wichtig“. Das Ergebnis ist eine Liste von Mittelwerten zwischen 3,8 und 4,4, und die Rangfolge darin ist Rauschen, weil niemand einem Feature „unwichtig“ gibt, das er vielleicht einmal braucht.
Wichtigkeitsskalen messen keine Trade-offs, und Produktentscheidungen sind Trade-offs. Das Team kann drei Features im Quartal bauen, nicht zwanzig, und es will wissen, welche drei die Nutzer wählen würden, wenn sie wählen müssten. Genau das misst MaxDiff.
Wie MaxDiff funktioniert
Die Befragten sehen nacheinander Sets von vier oder fünf Features und wählen in jedem Set das wichtigste und das unwichtigste. Die Sets sind so zusammengestellt, dass jedes Feature je Befragtem mehrfach vorkommt, in wechselnder Nachbarschaft. Aus vielen Sets je Befragtem und vielen Befragten entsteht für jedes Feature ein Score: wie oft es als wichtigstes gewählt wurde, minus wie oft als unwichtigstes, oder als Nutzenwert aus einem Logit-Modell.
Das Ergebnis ist eine Rangfolge mit Abständen. Feature A ist nicht „wichtiger“ als B; es wurde doppelt so oft als wichtigstes gewählt und halb so oft als unwichtigstes. Und weil die Befragten sich in jedem Set entscheiden mussten, gibt es keine Liste aus lauter „sehr wichtig“.
Vier Designregeln
- Acht bis 25 Items. Unter acht lohnt der Aufwand nicht; eine Wichtigkeitsskala reicht dann. Über 25 wird der Fragebogen zu lang und die Items zu ähnlich, und die Befragten beginnen zu raten.
- Vier bis fünf Items je Set, jedes Item drei- bis fünfmal je Befragtem. Bei zwölf Items und vier je Set sind das neun bis zwölf Sets, etwa drei Minuten. Mehr Sets je Befragtem liefern stabilere Werte; ab etwa 15 Sets sinkt die Sorgfalt.
- Items auf derselben Ebene. „Dunkler Modus“ neben „Bessere Performance“ ist ein Vergleich von Apfel und Obstkorb. Formulieren Sie Items als konkrete, vergleichbare Nutzerergebnisse: „Berichte automatisch jeden Montag per E-Mail erhalten“ statt „Automatisierung“.
- Die Frage klären, bevor die Sets gebaut werden. „Welches Feature ist Ihnen am wichtigsten?“ misst Wichtigkeit für die Roadmap. „Welches würden Sie am ehesten nutzen?“ misst Nutzungsabsicht. „Welches würde Sie am ehesten zum Wechsel bewegen?“ misst Positionierung. Alle drei sind legitim, keine zwei sind dasselbe.
Lassen Sie die Items von zwei Personen außerhalb des Teams gegenlesen. Ein Item, das nur das Team versteht, wird in den Sets zufällig gewählt und landet in der Mitte der Rangfolge, wo es nichts aussagt.
Stichprobe und Segmente
Eine Gesamtrangfolge wird erfahrungsgemäß ab etwa 150 Befragten stabil. Wer die Rangfolge je Segment braucht, sollte je Segment auf 100 kommen; das sind bei drei Plänen 300 Befragte. Die Unterschiede zwischen Segmenten sind oft kleiner als erwartet, und wer sie berichten will, prüft sie mit dem Signifikanztest.
Plan und Rolle müssen dafür nicht abgefragt werden. Ihre App kennt sie und hängt sie als URL-Parameter an den Umfragelink, etwa ?plan=team&rolle=admin; der Fragebogen bleibt bei den Sets. Laden Sie aktive Nutzer ein, nicht Registrierte: Wer das Produkt nicht nutzt, hat zu den Features keine Meinung, die Trade-offs abbildet.
Auswerten: die Rangfolge lesen
Die Auswertung liefert drei Darstellungen, die zusammen gelesen werden sollten.
- Die Präferenzrangfolge als Balken je Feature, mit den Abständen. Die Lücke zwischen Platz drei und Platz vier ist oft die wichtigste Information: Wenn sie groß ist, sind die ersten drei die Roadmap; wenn sie klein ist, muss das Team selbst entscheiden.
- Die Best-Worst-Tabelle mit dem Anteil als wichtigstes und dem Anteil als unwichtigstes je Feature. Ein Feature, das oft als wichtigstes und oft als unwichtigstes gewählt wird, polarisiert; es ist für ein Segment entscheidend und für ein anderes irrelevant, und die Rangfolge allein zeigt das nicht.
- Die Rangfolge je Segment als Vergleich: Was Admins wollen, was Anwender wollen, was der Enterprise-Plan anders gewichtet als der Team-Plan. Hier sind die Unterschiede meist die Roadmap-Diskussion wert, nicht die Gesamtrangfolge.
Legen Sie die MaxDiff-Rangfolge neben die codierten offenen Antworten aus der Microsurvey („Was fehlt Ihnen am meisten?“). Wo beide dasselbe sagen, ist die Entscheidung unstrittig. Wo sie auseinanderlaufen, wissen die Nutzer etwas, das die Items nicht abgebildet haben, und das nächste MaxDiff hat ein Item mehr.
Was MaxDiff nicht sagt
MaxDiff liefert eine Rangfolge der Wichtigkeit. Es sagt nicht, ob ein Feature fehlen darf. Ein Basismerkmal, dessen Fehlen verärgert, kann in der Rangfolge hinten liegen, weil es selbstverständlich ist; ein Begeisterungsmerkmal kann vorn liegen, weil es neu ist. Für diese Unterscheidung gibt es das Kano-Modell, das jedes Merkmal zweimal bewerten lässt, einmal enthalten und einmal fehlend; der Beitrag zum Kano-Modell beschreibt es. Und MaxDiff sagt nichts über Preise; dafür stehen Van Westendorp und die Conjoint-Analyse bereit.
In DataLion
Der MaxDiff-Fragetyp rendert die Auswahlsets im Fragebogen und rechnet im Dashboard Scores, Best-Worst-Anteile und Nutzenwerte aus einem aggregierten Logit-Modell, filterbar nach Plan und Rolle. Individuelle Nutzenwerte per Hierarchical Bayes rechnet DataLion nicht; für die Roadmap-Frage, welche fünf Features vorn liegen und ob der Team-Plan anders wählt als der Enterprise-Plan, reicht das aggregierte Modell. Wer HB braucht, exportiert die Daten und rechnet extern.
Nächster Schritt
Formulieren Sie zwölf bis 16 Feature-Items auf derselben Ebene, lassen Sie sie gegenlesen und öffnen Sie die MaxDiff-Vorlage. Hängen Sie Plan und Rolle als Parameter an, laden Sie aktive Nutzer ein und zielen Sie auf 150 Antworten. Die Rangfolge mit Abständen liegt danach im Dashboard, und die Roadmap-Runde hat eine Grundlage mit echten Abständen statt einer Spalte „sehr wichtig“. Das Gesamtbild für Produktteams zeigt die Seite UX Research und Produktforschung.