User Research, das die Roadmap bewegt, nicht nur Vermutungen bestätigt

Die PM hatte bereits entschieden. Das Roadmap-Dokument war drei Sprints tief, die Jira-Tickets waren entworfenen, und die Engineering-Managerin hatte eine grobe Schätzung. Dann sagte das Design-Org "wir sollten wahrscheinlich zuerst mit Nutzern sprechen", und ein Research-Projekt wurde angesetzt.

Fünf Calls. Fünf Kunden, die die CSM ausgewählt hatte, weil sie "engagiert und gesprächsbereit" waren. Ein Notion-Dokument mit sechzehn Zitaten, vier davon leicht unterstützend, keines überraschend. Die PM las die Zusammenfassung, sagte "das bestätigt, was wir dachten", und lieferte das Feature sechs Monate später. Die Adoptionsrate lag bei 11 %. Das Post-Launch-Retro bezeichnete es als ein "Messaging-Problem".

Es war kein Messaging-Problem. Es war ein Research-Problem, verkleidet als User Research. Die Studie scheiterte nicht, weil die Methodik falsch war. Sie scheiterte, weil niemand bereit war, die Entscheidung davon ändern zu lassen. Das ist kein Research. Das ist eine Zeremonie.

Wenn Sie in dieser Schleife stecken und müde davon sind, ist das das Playbook. Es deckt ab, wann welche Art von Research einzusetzen ist, wie Studien richtig dimensioniert werden, wie man Erkenntnisse schreibt, die eine skeptische PM überleben, und wie man der "Nutzer sagten, sie wollen X"-Falle entkommt, die SMB-Roadmaps still zu Gunsten desjenigen opfert, der beim letzten QBR am lautesten geschrien hat.

Generative versus evaluative Forschung: zuerst das richtige Werkzeug wählen

Der schnellste Weg, ein Research-Budget zu verschwenden, ist das falsche Kategorie zu wählen. Generative Forschung beantwortet "welches Problem lösen wir?" Evaluative Forschung beantwortet "löst das Ding, das wir gebaut haben, es?" Sie sehen von außen ähnlich aus (beide involvieren Nutzer, beide produzieren Zitate), aber sie beantworten Fragen in entgegengesetzte Richtungen und erfordern unterschiedliche Stichprobengrößen, unterschiedliche Rekrutierung und unterschiedliches Stakeholder-Buy-in.

Die meisten B2B-SaaS-Teams greifen nach evaluativer Forschung, wenn die eigentliche Frage generativ ist. Jemand sagt "wir müssen das neue Dashboard testen", und ein Usability-Test wird angesetzt, bevor jemand gefragt hat, ob das Dashboard überhaupt gebaut werden sollte. Wenn der Test läuft, ist die mögliche Antwort eng: finden Nutzer die Buttons. Die wichtige Frage (sollte dieses Dashboard existieren?) ist nun vom Tisch, weil der Prototyp bereits gebaut ist.

Verwenden Sie die Tabelle als Entscheidungshilfe. Bevor Sie eine Studie spezifizieren, schreiben Sie die Entscheidung auf, die das Team gleich treffen wird. Wenn die Entscheidung lautet "sollten wir das bauen?", brauchen Sie generative Forschung. Wenn sie lautet "sollten wir die Version liefern, die wir gebaut haben?", brauchen Sie evaluative. Wenn sie lautet "sollten wir die gelieferte Version weiterentwickeln?", brauchen Sie kontinuierliche. Die meisten "wir brauchen User Research"-Anfragen sind tatsächlich eine dieser drei, und der Anfragende weiß meistens nicht, welche.

Der 5-Nutzer-Usability-Test: Nielsens tatsächliche Regel, nicht das Meme

Jakob Nielsens Studie aus dem Jahr 1993 ergab, dass 5 Nutzer ausreichen, um ungefähr 85 % der Usability-Probleme in einer Studie aufzudecken. Diese Zahl wurde zu "immer mit 5 testen" komprimiert und wird seit dreißig Jahren von Menschen zitiert, die das Paper nicht gelesen haben. Die 5-Nutzer-Regel gilt unter bestimmten Bedingungen, und diese Bedingungen sind enger, als die meisten Produktteams es handhaben.

Die Regel gilt, wenn Sie ein Nutzersegment haben, das eine Aufgabe auf einer Oberfläche erledigt. Ein neuer Nutzer meldet sich an. Ein Administrator konfiguriert eine einzelne Einstellung. Ein Endnutzer reicht einen Ausgabenbericht ein. In diesem Rahmen gilt die Mathematik: Mit Nutzer 5 haben Sie die meisten Probleme gesehen, und ab Nutzer 8 sehen Sie Wiederholungen.

Die Regel bricht, sobald eine dieser Bedingungen bricht:

• Mehrere Personas. Wenn Ihr B2B-Produkt Administratoren, Endnutzer und IT hat, brauchen Sie 5 von jedem. Das sind 15 Sessions, nicht 5. Administratoren werden durch Dinge verwirrt, die Endnutzer nie sehen.
• Konzeptuelle, nicht interaktionale Probleme. Die 5-Nutzer-Regel fängt "Ich konnte den Button nicht finden." Sie verfehlt "Ich verstehe nicht, warum diese Funktion existiert." Konzeptuelles Missverständnis tritt pro Nutzer mit geringer Rate auf, ist aber bedeutsamer; Sie brauchen 12 bis 15, um es zuverlässig zu erkennen.
• Verzweigte Workflows. Ein linearer Anmelde-Flow lässt sich gut mit 5 testen. Ein Workflow mit 6 bedingten Verzweigungen braucht Stichprobenabdeckung für jede Verzweigung. Sie können 5 Nutzer einsetzen und zusehen, wie 4 von ihnen die Verzweigung nie treffen, wo der Fehler liegt.
• Segmentübergreifender Vergleich. Wenn die Frage lautet "funktioniert das für SMB und Enterprise?", brauchen Sie eine Studie, die für einen Segmentvergleich dimensioniert ist, was mindestens 8 bis 12 pro Segment bedeutet.

Wenn ein Stakeholder sagt "machen wir einfach 5", fragen Sie nach der Persona, der Aufgabe und der Entscheidung, die das Ergebnis informieren wird. Wenn die Entscheidung lautet "liefern oder nicht liefern, über unser gesamtes Nutzerbasispublikum", sind 5 nicht genug. Wenn die Entscheidung lautet "ist dieser Anmelde-Flow für neue SMB-Nutzer speziell kaputt", könnten 5 genau richtig sein.

Unmoderiertes Testing: Maze, UserTesting, Lyssna und was sie verbergen

Unmoderierte Plattformen haben verändert, wie schnell ein Designer eine evaluative Studie durchführen kann. Maze, UserTesting und Lyssna erlauben es, einen Prototyp an 50 Tester zu senden und bis Freitag Ergebnisse zu haben. Die Geschwindigkeit ist real. Ebenso die Kosten.

Unmoderiertes Testing gewinnt bei drei Dingen: Geschwindigkeit (24 bis 72 Stunden Durchlaufzeit), Reichweite (man kann Panels rekrutieren, die man für ein moderiertes Gespräch nie erreichen würde) und quantitativer Vergleich (A/B zwei Designs in großem Maßstab). Für klare, kontextarme Aufgaben für ein breites Publikum ist es schwer zu schlagen.

Es verliert bei drei Dingen, und B2B-Produkte laufen in alle drei:

1. Komplexe Workflows. Moderierte Studien erlauben es, einem Nutzer beim Denken zuzusehen, "warum haben Sie darauf geklickt?" zu fragen und nachzuhaken, wenn er steckenbleibt. Unmoderiert erhalten Sie ein Video von jemandem, der in Stille auf das Falsche klickt und weitermacht. Sie erfahren, dass er scheiterte. Sie erfahren nicht warum.
2. Fachjargon-lastige Oberflächen. B2B-Produkte sind voll von Begriffen, die Nutzer nur im Kontext verstehen. Ein unmoderierter Tester aus einem Panel rät, scheitert und bewertet den Test als "einfach", weil er nicht weiß, was er nicht weiß. Der Test produziert sauber aussehende Daten und stille Verständnislücken.
3. Die "Warum"-Frage. Alles, was das Verstehen von Absicht, Motivation oder Abwägungsüberlegungen erfordert, braucht einen Moderator. Unmoderierte Tools haben sich bei Nachfolgefragen verbessert, aber eine aufgezeichnete Folgefrage bekommt eine einstudierte Antwort. Ein Live-Moderator bekommt die echte.

Realistische Abschlussraten bestätigen das. Für verbraucherorientierte Aufgaben laufen unmoderierte B2C-Tests mit 80 bis 95 % Abschluss. Für B2B-SaaS-Workflows sollten Sie mit 60 bis 75 % rechnen. Diese Lücke ist wichtig bei der Dimensionierung: eine Studie, die n=20 gültige Sessions für einen B2B-Workflow braucht, benötigt 28 bis 32 Starts, um das zu erreichen. Planen Sie für den Ausfall.

Die häufigste Falle: Teams wählen unmoderiert, weil es schnell ist, und treffen dann Entscheidungen, die moderierte Tiefe brauchten. Maze sagt Ihnen die Klickrate. Es sagt Ihnen nicht, dass 4 von 12 SMB-Nutzern keine Ahnung hatten, was "Tenant" in Ihrem IT-Einstellungsfeld bedeutete, und einfach die richtige Antwort geraten haben.

Die "Research zeigte, dass Nutzer X wollen"-Falle

Hier stirbt die meiste B2B-Research. Auswahlverzerrung, Aktualitätsverzerrung und Bestätigungsverzerrung häufen sich, und eine Studie mit acht Teilnehmern wird zum Roadmap für ein Publikum, das Sie nicht haben.

Auswahlverzerrung entsteht dadurch, wer den Anruf beantwortet. Customer Success wählt die engagierten Kunden, weil sie E-Mails beantworten. Engagierte Kunden sind eher Enterprise, eher Administratoren und wollen eher Funktionen, die ihren bestehenden Workflow leistungsfähiger machen. Befragen Sie 8 von ihnen und Sie hören eine einheitliche Botschaft: mehr Berechtigungen, mehr Rollen, mehr Enterprise-taugliche Kontrollen. Wenn Ihr Geschäft zu 70 % SMB nach ARR ist, haben Sie gerade eine Studie für die 30 % durchgeführt, die ohnehin keine Hilfe brauchten.

Aktualitätsverzerrung entsteht durch den letzten lauten Kunden. Letzte Woche fand ein QBR statt, der VP hörte von einem 400.000-Dollar-Account, und "Nutzer wollen SSO" steht jetzt als Zitat ohne n im Planungsdokument. Wenn Research rekrutiert wird, lautet die Frage nicht mehr "wollen Nutzer SSO?", sondern "wie stark wollen Nutzer SSO?", und die Rekrutierung filtert nach Nutzern, die SSO wertvoll fänden.

Bestätigungsverzerrung liegt in den Fragen selbst. "Wäre es nützlich, wenn Sie Berichte in großen Mengen exportieren könnten?" bekommt von fast jedem ein Ja. "Wie gehen Sie derzeit mit Berichten um?" sagt Ihnen, ob Massenexport ein echter Engpass oder ein Nice-to-have ist, das unter den zehn Dingen begraben liegt, mit denen sie täglich kämpfen.

Ein echtes, anonymisiertes Beispiel: Eine Studie mit 8 Administratoren von 3 Enterprise-Accounts produzierte die Überschrift "Nutzer wollen SSO". Der Roadmap verschob sich zu einem Quartal SSO- und SCIM-Arbeit. Sechs Monate später stieg die SMB-Abwanderung, weil das Team, das für Aktivierung zuständig war, zum SSO-Projekt gezogen worden war. Die 8 Administratoren waren zufrieden. Die 1.400 SMB-Accounts, die es nie bis Woche 2 der Aktivierung schafften, wurden nicht befragt. Die Studie lag nicht falsch in Bezug auf die 8 Administratoren. Sie lag falsch darin, als Studie über "Nutzer" behandelt zu werden.

Die Verteidigung ist verfahrensmäßig. Bevor Sie rekrutieren, schreiben Sie auf: welches Segment betrifft diese Studie, welchen Anteil am Umsatz repräsentiert dieses Segment, und welche Entscheidungen kann diese Studie legitim informieren? Wenn die Antwort auf die dritte Frage lautet "nur Entscheidungen über dieses Segment", stellen Sie das auf die Titelfolie des Readouts. Stakeholder werden zu weit verallgemeinern, wenn Sie den Scope nicht explizit machen.

Wie man eine Erkenntnis schreibt, die eine Entscheidung ändert

Die meisten Research-Erkenntnisse sterben auf der Folie, auf der sie stehen. "Nutzer waren von dem Export-Button verwirrt" verliert jedes Argument, weil es kein n, kein Segment, keine Spezifität und keine Empfehlung hat. Es kann wahr sein und trotzdem ignoriert werden.

Eine Erkenntnis, die eine skeptische PM überlebt, hat fünf Teile:

1. Beobachtung: was behavioristisch passiert ist
2. Beleg: n, Segment, Aufgabe, Studientyp
3. Schlussfolgerung: was das wahrscheinlich bedeutet
4. Empfehlung: was dagegen zu tun ist
5. Vertrauensgrad: wie sicher Sie sind

Vergleich:

Schlecht: Nutzer waren von dem Export-Button verwirrt.

gegenüber:

Gut: 6 von 8 Administratoren (n=8, Enterprise-Tier, moderierter Usability-Test, Wochenberichts-Export-Aufgabe) brachen den Export-Workflow beim Formatauswahl-Schritt ab. Drei sagten laut, dass sie nicht wüssten, was "getrennt" bedeutete; zwei klickten das falsche Format und bemerkten es nicht. Schlussfolgerung: Der Format-Selektor ist ein Verständnishindernis, kein Auffindungsproblem. Empfehlung: CSV als Standard setzen mit einem "Weitere Formate"-Aufklappmenü, hinter einem Flag liefern und die Abbruchdelta messen. Vertrauensgrad: mittel. Die Stichprobe ist klein und nur Enterprise; ein 2-wöchiges unmoderiertes Follow-up über SMB würde das bestätigen.

Die zweite gewinnt, weil sie der PM genau sagt, was bekannt ist, was abgeleitet wurde, und welche Aktion folgt. Die skeptische PM kann jeden der fünf Teile angreifen, muss aber einen spezifischen Teil angreifen. Sie kann nicht einfach "kleine Stichprobe" sagen und gehen, weil die Empfehlung das bereits mit einem Follow-up-Plan berücksichtigt.

Ein zweites Muster, das hilft: Erkenntnisse mit der Entscheidung beginnen, die sie betreffen, nicht mit der Methodik. "Wir müssen den Export-Standard ändern" landet gut. "Wir führten eine moderierte Studie mit 8 Administratoren durch" schläfert das Publikum ein, bevor die Empfehlung ankommt.

Research einer skeptischen PM präsentieren

Ein 23-foliiger Research-Deck, der einer PM im Standup übergeben wird, wird die Roadmap nicht ändern. Er wird zur Kenntnis genommen, abgelegt und ignoriert. PMs sind Entscheidungsträger unter Zeitdruck. Research muss sie dort abholen, wo sie sind.

Fünf Dinge, die tatsächlich funktionieren:

Mit der Entscheidung beginnen. Öffnen mit "diese Studie informiert darüber, ob wir den neuen Export-Flow wie geplant liefern, mit einer Änderung liefern oder neu bauen." Dann die Methodik, dann die Erkenntnisse. Die PM liest jetzt, um eine Entscheidung zu treffen, nicht um Research zu evaluieren.

Den Gegenzug vorbereiten. Bevor Sie präsentieren, schreiben Sie die drei Einwände auf, die Sie erwarten ("kleine Stichprobe", "das sind nicht unsere ICP", "wir haben bereits entschieden"). Sprechen Sie jeden im Deck an, bevor er geäußert wird. "n=8 ist zu klein für segmentübergreifende Behauptungen, weshalb diese Studie nur zu Enterprise-Administratoren bei der Export-Aufgabe spricht" entwaffnet den Kleinstichproben-Angriff, bevor er landet.

Den Rohclip mitbringen, nicht die Zusammenfassung. Ein 45-Sekunden-Video eines Administrators, der die Format-Dropdown betrachtet und sagt "Ich habe keine Ahnung, was das alles bedeutet" ist fünfzehn Zitierfolien wert. PMs vertrauen ihren eigenen Augen mehr als Ihrer Synthese. Tools wie Dovetail und UserTesting machen das schnelle Herausschneiden von Clips einfach.

An einer Kennzahl verankern, die der PM bereits wichtig ist. Wenn die PM Aktivierung verantwortet, rahmen Sie Erkenntnisse um den Aktivierungseffekt. Wenn sie Retention verantwortet, rahmen Sie um Retention. "Diese Export-Reibung betrifft die Woche-2-Aktivierung für neue Administratoren" schlägt "diese Export-Reibung ist ein UX-Problem" jedes Mal.

Die Kosten des Ignorierens benennen. "Wenn wir wie geplant liefern, erwarten wir, dass ungefähr 30 bis 40 % der neuen Administratoren die Export-Aufgabe im ersten Monat abbrechen, basierend auf der moderierten Sitzungsabbruchrate" gibt der PM etwas, das sie gegen das Lieferdatum abwägen kann.

Eine praktische Regel: wenn eine Research-Erkenntnis nicht auf eine einzige Folie mit der Entscheidung, dem Beleg, der Empfehlung und einem Zitat passt, ist es noch keine Erkenntnis. Es ist ein Notizbucheintrag. Arbeiten Sie weiter daran, bevor es in den Raum geht.

Was Sie diese Woche tun können

Wählen Sie eine bevorstehende Roadmap-Entscheidung. Schreiben Sie auf, was entschieden wird, wer es entscheidet und was wahr sein müsste, damit die Entscheidung kippt. Dann fragen Sie: hat das Team Belege für das, was wahr sein müsste? Wenn nicht, das ist die Studie. Wenn ja, wurde die Research bereits gemacht und der nächste Schritt ist, sie sichtbar zu machen.

Research, das die Roadmap bewegt, ist Research, das auf eine spezifische Entscheidung abzielt, für die Behauptung dimensioniert ist, die es unterstützen muss, und in einer Form präsentiert wird, auf die eine beschäftigte PM reagieren kann. Alles andere ist ein Workshop. Workshops sind in Ordnung. Verwechseln Sie sie nur nicht mit Studien.

Weiterführende Inhalte

• Design Critique, das die Arbeit verbessert, nicht die Stimmung des Designers
• Mit PMs arbeiten, die Design für Dekoration halten
• Liefergeschwindigkeit für Designer
• Product Designer Job Description Template