Formulare fuer Product Management

Die NPS-Frage selbst ist trivial — eine Skala von 0 bis 10, eine Standard-Formel. Was die meisten Teams falsch machen, ist alles drumherum: falsches Timing (gleich nach Signup, wenn der User noch nichts erlebt hat), zu viele Fragen (NPS soll kurz sein, sonst sinkt die Antwortrate unter zehn Prozent), kein Detraktor-Follow-up (der wertvollste Datenpunkt verpufft).

Gutes NPS-Setup: Trigger nach echtem Wert-Erlebnis (nach dem dritten Login, nach dem ersten echten Use-Case-Abschluss). Eine Hauptfrage, eine optionale Folgefrage. Bei Detraktoren (0-6) ein Follow-up, das nach dem konkreten Frust fragt — nicht "Warum?", sondern "Was fehlt dir?".

Fuer dich als PM heisst das: Conditional Logic blendet das Follow-up nur fuer Detraktoren ein. Promoter (9-10) bekommen einen Slot fuer einen Case-Study-Call, Passives (7-8) bekommen nichts. Ein Slack-Webhook feuert bei jeder Detraktor-Antwort sofort an dein Customer-Success-Team — du kannst telefonieren, bevor der Kunde kuendigt. NPS wird vom Vanity-Score zum operativen Werkzeug.

Jedes Feature, das du baust, ist ein Feature, das du nicht baust. Engineering-Stunden sind die teuerste Ressource im Unternehmen — und das Schlimmste, was du tun kannst, ist drei Sprints in etwas zu stecken, das niemand benutzt. Bauchgefuehl reicht da nicht.

Feature-Validation per Formular kostet zwei Stunden Setup und beantwortet die wichtigste Frage vor dem Coden: Ist der Schmerz echt? Schick eine Beschreibung des geplanten Features an einen Cohort von dreissig Power-Usern, frag konkret: Wie loest du das heute? Was kostet dich das? Wuerdest du fuer eine Loesung X Euro pro Monat zahlen? Per Calculation Engine berechnest du direkt einen RICE-Score (Reach * Impact * Confidence / Effort).

Noch besser: Wertversprechen-Test. Du beschreibst das Feature nicht als "Wir bauen X", sondern als "Bald gibt es X — willst du auf die Beta-Liste?". Conversion auf den Beta-Button ist ein harter Preference-Indikator. Liegt sie unter zehn Prozent, baust du das Feature nicht. Drei Stunden Recherche ersparen dir drei Wochen Engineering.

Klassische User-Research ist ein Quartals-Event: drei Wochen Vorbereitung, zwoelf Interviews, ein Bericht den niemand liest, und dann sechs Monate Stille. Das Problem: Produktentscheidungen passieren jeden Tag, nicht alle drei Monate.

User-Research light kehrt das Modell um. Statt einer grossen Studie betreibst du viele kleine Mini-Surveys mit drei bis fuenf Fragen, eingebettet an konkreten Touchpoints: nach einem Onboarding-Schritt, nach einem Feature-Use, nach einem Cancellation-Klick. Jede Submission ist ein Datenpunkt — und durch den hohen Throughput siehst du Trends in Echtzeit, nicht erst beim naechsten Quartals-Review.

Fuer dich als PM heisst das: Du betreibst ein Research-System, kein Research-Projekt. Per Hidden Fields uebergibst du Plan, Cohort und Feature-Kontext an jede Submission. In der Auswertung filterst du nach Cohort und siehst sofort, ob Power-User anders ueber das neue Feature denken als Trial-User. Aus drei grossen Studien pro Jahr werden dreissig kleine Insights pro Monat.