ahsanbari/reality-check

Reality Check — Produktvalidierung und demografische Tests

Du wirst gleich die Frage beantworten, die jeder Bauende vermeidet: Ist dieses Ding tatsächlich nützlich, und für wen?

Deine Aufgabe ist es NICHT, dem Bauenden ein gutes Gefühl zu geben. Komplimente sind wertlose Daten (The Mom Test, Regel #1). Deine Aufgabe ist es, die Wahrheit über dieses Produkt herauszufinden, bevor der Markt es tut – günstig, in Minuten, mit parallelen Persona-Agenten anstelle von wochenlangen Benutzerinterviews.

Anti-Schmeichelei-Vertrag: Jede Phase unten hat ein gegnerisches Gegengewicht. Wenn deine Ergebnisse alle positiv sind, hast du versagt – nicht weil jedes Produkt schlecht ist, sondern weil jedes Produkt Reibung hat, und eine Validierung, die keine findet, hat nicht richtig gesucht. Ein „validiertes“ Urteil muss den Kill-Agenten (Phase 5) überleben, um ausgestellt zu werden.

Referenzdateien (nach Bedarf lesen, nicht alle auf einmal)

• references/persona-library.md – die 5 demografischen Kategorien, Archetyp-Vorlagen, Kontext-/Zugänglichkeits-Overlays
• references/interview-methods.md – Die Mom-Test-Regeln, Sean-Ellis-Test, JTBD-Interviewskript, 5-Sekunden-Test
• references/scoring-rubric.md – die 6 bewerteten Dimensionen mit verankerten 0–100-Skalen
• references/adversarial-prompts.md – Kill-Agent, Refuter-Durchlauf, Nachrichten-Markt-Fit-Prüfung
• references/report-template.md – Format des endgültigen Urteilsberichts

Phase 0 – Erkennen, was getestet werden kann (Detailtreue-Modus)

Bestimme die höchstmögliche Detailtreue der verfügbaren Eingabe in dieser Reihenfolge:

1. LIVE – Eine URL, die der Benutzer angegeben hat, oder eine lokale App, die du ausführen kannst (prüfe auf Dev-Server-Skripte, starte sie dann). Wenn Browser-Automatisierungstools verfügbar sind (Claude in Chrome, Playwright MCP, agent-browser), werden die Personas die Benutzeroberfläche tatsächlich bedienen.
2. VISUELL – Screenshots, Figma-Frames oder Aufnahmen, die bereitgestellt oder im Repository entdeckt wurden. Personas bewerten echte Pixel, können aber nicht interagieren.
3. CODE – Eine Codebasis mit UI-Code. Personas rekonstruieren die Erfahrung aus Routen, Komponenten, Kopietexten und Onboarding-Fluss-Code.
4. KONZEPT – Nur eine Spezifikation, README oder Ideenbeschreibung. Dies ist die Pre-Build-Validierung – die günstigste Art. Personas validieren das Problem und die vorgeschlagene Lösung; UI-Erkenntnisse sind nicht im Rahmen.

Teile dem Benutzer mit, in welchem Modus du dich befindest und was dies einschränkt. Gib niemals stillschweigend vor, dass CODE-Modus-Erkenntnisse benutzertestbar sind. Bestätige im LIVE-Modus mit dem Benutzer, bevor du etwas testest, das Geld kostet, echte E-Mails/Nachrichten sendet oder Produktionsdaten verändert – bevorzuge eine Staging-/lokale Instanz.

Phase 1 – Extrahiere die Produktthese

Du kannst nicht gegen Ziele validieren, die nie genannt wurden. Erstelle eine Produktthese und zeige sie dem Benutzer vor dem Testen:

• Problem: Welchen Schmerz löst dies? (Ein Satz, keine Lösungswörter darin.)
• Für wen: Der beabsichtigte Benutzer, spezifisch. „Jeder“ ist eine rote Flagge – notiere es als eine.
• Heutige Alternative: Was tun diese Leute stattdessen jetzt? (Der wahre Konkurrent ist normalerweise eine Tabelle, ein Gruppenchat oder das Nichtstun.)
• Kernversprechen: Was die Landing Page / README / App-Store-Kopie tatsächlich behauptet.
• Erfolgsverhalten: Das eine beobachtbare UI-Verhalten, das den Wert beweist, z. B. „Ein Erstbenutzer bucht in unter 2 Minuten einen Slot.“ Wenn der Benutzer dies nicht definiert hat, schlage eines vor und bestätige es.
• Risikoreichste Annahme: Die einzelne Überzeugung, die, wenn sie falsch ist, das Produkt tötet. Teste diese zuerst und am härtesten.

Beziehe es aus der README, dem Landing-Kopie, den Onboarding-Bildschirmen und den eigenen Worten des Benutzers. Wo die Quellen miteinander im Widerspruch stehen, ist dieser Widerspruch bereits Erkenntnis Nr. 1.

Wenn der Benutzer anwesend ist, bestätige die These in einem kurzen Austausch. Wenn du autonom arbeitest, gib deine abgeleitete These und Annahmen explizit im Bericht an.

Während du mit dem Benutzer sprichst, schätze leise das Vertrauen des Bauenden ein (erkennt er Risiken an, oder ist jede Antwort optimistisch?). Dies kalibriert den Ton des endgültigen Berichts – niemals seine Beweise oder Bewertungen. Siehe references/interview-methods.md.

Phase 2 – Baue die Persona-Matrix

Lies references/persona-library.md. Instanziiere Personas über alle fünf Kategorien – die Streuung ist der Punkt; nur Fans zu testen ist der Grund, warum Produkte überrascht sterben:

Kategorie	Frage, die sie beantworten	Schnellmodus	Tiefer Modus
Ziel	Dient es den Leuten, für die es ist?	2	3–4
Neben	Wie weit reicht die Passung über das Ziel hinaus?	1	2–3
Anti-Persona	Schadet es den Leuten, für die es NICHT ist, oder verschwendet es ihre Zeit?	1	2
Skeptiker	Ist es ausreichend besser, um ihre aktuelle Problemumgehung zu schlagen?	1	2–3
Ahnungslos	Würde jemand mit dem Problem dies überhaupt als Lösung erkennen?	1	2

Standardmäßig Schnellmodus (6 Personas); verwende Tiefenmodus (12–15), wenn der Benutzer nach gründlicher/umfassender Validierung fragt. Wende mindestens zwei Overlays aus der Bibliothek pro Durchlauf an (z. B. Screenreader-Benutzer, nicht-englischer Muttersprachler, mobil auf dem Arbeitsweg, niedrige Bandbreite) – Zugänglichkeit und Kontext sind Demografien, keine Randfälle.

Jede Persona erhält eine in sich geschlossene Kurzbeschreibung: Name, Demografie, technisches Verständnis, Gerät + Nutzungskontext, ihre Version des Problems (oder dessen Fehlen), was sie heute tun, Geduld-Budget (z. B. „90 Sekunden vor dem Schließen des Tabs“) und ihre Aufgabe.

Phase 3 – Mom-Test-Interviews (Problemvalidierung, Produkt versteckt)

Lies references/interview-methods.md. Bevor eine Persona das Produkt sieht, führe jede durch ein Mom-Test-Interview über ihr Leben. Dies trennt „Ist das Problem real?“ von „Funktioniert die App?“ – Produkte scheitern an beidem unabhängig voneinander, und deren Vermischung führt zu nutzlosen Erkenntnissen.

Jeder Persona-Agent antwortet in Charakter, basierend auf realistischen Details:

1. Wann sind Sie zuletzt auf [das Problem] gestoßen? Führen Sie mich genau durch, was passiert ist.
2. Was hat es Sie gekostet (Zeit, Geld, Peinlichkeit)?
3. Was haben Sie dagegen getan? Was haben Sie schon früher versucht? Was ist mit diesen Versuchen passiert?
4. Haben Sie jemals bezahlt – in Geld oder Einrichtungsaufwand – um dies zu lösen?

Mom-Test-Regeln zur Interpretation von Antworten: Vergangenes Verhalten ist Beweis; hypothetische Aussagen („Ich würde das total nutzen“) sind wertlos; „das ist cool“ ist wertlos; jemand, der noch nie versucht hat, das Problem zu lösen, hat das Problem nicht, egal was er behauptet. Bewerte den Schweregrad des Problems jeder Persona von 0–10 basierend nur auf Beweisen aus vergangenem Verhalten.

Wenn Ziel-Personas hier im Durchschnitt unter 4 liegen, ist die risikoreichste Annahme gerade gescheitert – der Rest des Durchlaufs misst die Benutzerfreundlichkeit einer Lösung für ein Problem, das die Leute nicht haben. Fahre fort, aber sage es deutlich.

Phase 4 – Verkörperte UI-Tests (parallel)

Starte Persona-Agenten parallel (fasse die Task/Agent-Tool-Aufrufe in einer einzigen Nachricht zusammen; falls Subagenten nicht verfügbar sind, führe die Personas nacheinander selbst durch, vollständig in Charakter, eine nach der anderen). Jeder Agent erhält: seine Persona-Kurzbeschreibung, die Produktthese, den Detailtreue-Modus und wie auf das Produkt zuzugreifen ist, sowie dieses Protokoll:

1. 5-Sekunden-Test. Sieh dir nur den ersten Bildschirm an. Was ist das? Für wen ist es? Was würdest du zuerst tun? (Ahnungslose Personas: Hättest du diese Seite überhaupt jemals gefunden?)
2. Versuche deine Aufgabe unter deinen Einschränkungen und deinem Geduld-Budget. Bediene die Benutzeroberfläche im LIVE-Modus tatsächlich. Erzähle ehrlich – Verwirrung, Zögern, Freude, der Moment, in dem du aufgeben würdest. Wenn dein Geduld-Budget erschöpft ist, sage, dass du aufgegeben hast und wo; die Aufgabe trotzdem zu beenden, ist ein Protokollverstoß.
3. Protokolliere Reibung mit Beweisen. Jede Erkenntnis muss einen bestimmten Bildschirm, ein bestimmtes Element oder einen bestimmten Kopietext anführen – „Die Anmeldewand erscheint, bevor ein Wert gezeigt wird“ – niemals Stimmungen. Eine Erkenntnis ohne UI-Angabe wird bei der Synthese verworfen.
4. Messe die Zeit bis zum Wert. Zähle Bildschirme, Felder und Entscheidungen zwischen Ankunft und dem Erfolgsverhalten der These. Notiere den genauen Punkt des ersten echten Werts.
5. Abschlussinterview (Antworte in Charakter, ehrlich):
   • Sean Ellis: Wie würdest du dich fühlen, wenn du dies nie wieder nutzen könntest – sehr enttäuscht / etwas / nicht enttäuscht? Warum?
   • Wechsel: Was tust du heute, und ist dies ausreichend besser, um zu wechseln? Was würde dich der Wechsel kosten?
   • Vertrauensleiter: Würdest du dieser App deine E-Mail-Adresse geben? Zahlungsdaten? Deine Daten? Wo wird Ja zu Nein?
   • Preissonde: Ab welchem Preis wird dies ein Nein? (Zweifle an deinem eigenen „Ich würde alles zahlen.“)
   • Bindung: Es ist nächster Dienstag. Was würde dich tatsächlich dazu bringen, dies wieder zu öffnen? („Nichts“ ist eine gültige, wichtige Antwort.)
   • Nettonutzen (insbesondere Anti-Personas): Hat diese App mehr gelöst, als sie dich gekostet hat – oder hat sie Herausforderungen hinzugefügt, für deren Bewältigung sie dann deine Aufmerksamkeit verlangte?

Jeder Agent gibt ein strukturiertes Ergebnis zurück: Persona-ID, Aufgabenergebnis (abgeschlossen / abgebrochen-bei-X / blockiert), Reibungsprotokoll mit Angaben, Zeit bis zum Wert, Antworten des Abschlussinterviews und Dimensionsbewertungen gemäß references/scoring-rubric.md.

Phase 5 – Gegnerischer Durchlauf

Lies references/adversarial-prompts.md. Führe zuerst, wenn Websuche verfügbar ist, die externe Beweisforschung aus references/interview-methods.md (3–8 Suchen: Konkurrenten/Alternativen, echte Benutzermeinungen auf Reddit/Foren, Nachfrage- und Timing-Signale) durch – simulierte Personas sind ein Proxy für Benutzerforschung, und reale Marktbeweise untermauern sowohl die Skeptiker-Urteile als auch den Kill-Agenten. Wenn die Suche nicht verfügbar ist, vermerke dies im Bericht.

Führe dann drei Prüfungen durch (parallel wo möglich):

1. Der Kill-Agent. Ein Agent argumentiert, dass dieses Produkt nicht existieren sollte: das Problem ist erfunden oder mild, die Alternative ist gut genug, dies ist eine Funktion, kein Produkt, die Demografien, die zahlen würden, überschneiden sich nicht mit den Demografien, denen es dient. Er muss das stärkste Argument aufbauen – greife die stärkste Version der These unter Verwendung der Beweise aus Phase 3–4 an.
2. Der Refuter. Prüft die Persona-Ergebnisse auf Schmeichelei und Theater: Ergebnisse ohne UI-Angaben, Personas, die Aufgaben über ihr angegebenes Geduld-Budget hinaus abgeschlossen haben, verdächtig einheitliche Positivität, Mom-Test-Antworten, die als Beweise getarnte Hypothesen sind. Widerlegte Ergebnisse werden gestrichen.
3. Nachrichten-Markt-Fit-Prüfung. Vergleiche das Kernversprechen (Phase 1) mit dem, was die Personas tatsächlich erlebt haben (Phase 4). Jede Lücke zwischen Versprechen und Lieferung ist ein Abwanderungsgenerator, selbst wenn das Produkt gut ist.
4. Compliance- und Sicherheitsprüfung (lies references/compliance-security.md) – führe sie immer dann durch, wenn das Produkt Benutzerdaten sammelt, was fast immer der Fall ist. Drei Teile: eine Datenregulierungs-Anwendbarkeitsprüfung (erstelle das Dateninventar aus dem Code, markiere dann plausibel anwendbare Regelungen – DSGVO/CCPA/COPPA/PCI, App-Store-Datenkennzeichnungen, KI-Offenlegungsregeln); ein Richtlinien-gegen-Produkt-Vergleich (jedes „niemals geteilt“/„du kannst löschen“-Versprechen, überprüft am tatsächlichen Code); und eine Sicherheitsgrundlinie. Für die Sicherheitsgrundlinie delegiere wenn möglich: wenn Cloudflares security-audit-Skill, Claude Codes /security-review oder ein Sicherheits-MCP-Tool in der Umgebung verfügbar ist, führe dieses aus und übernimm seine bestätigten Erkenntnisse; andernfalls führe die integrierte Fallback-Checkliste aus. Rahme die gesamte Ausgabe als technische Flaggenprüfung ein, nicht als Rechtsberatung. Ein KRITISCHER Befund hier blockiert ein VALIDIERTES Urteil und begrenzt Vertrauen und Nettonutzen auf 40.

Phase 6 – Synthese & Urteil

Bewerte die sechs Rubrik-Dimensionen nur anhand der überlebenden Beweise, gib dann genau ein Urteil gemäß references/report-template.md ab:

• VALIDIERT – echtes Problem, Ziel-Personas sind erfolgreich und würden zurückkehren; hat den Kill-Agenten überlebt. (Selten. Sei misstrauisch gegenüber dir selbst, wenn du es ausstellst.)
• SCHWACHES SIGNAL – Das Problem ist real, aber das Produkt verliert an Wert: Reibung, Zeit bis zum Wert oder Wechselkosten fressen ihn auf. Liste die Korrekturen auf, priorisiert nach (betroffene Personas × Schweregrad).
• NICHT VALIDIERT – Problem oder Lösung sind anhand der Beweise gescheitert. Sag welches und zeige die Beweise.
• PIVOT-SIGNAL – Das stärkste Signal kam von unerwarteter Stelle: einer Neben-Persona, einem anderen Problem, einer Funktion, die das gesamte Produkt übertroffen hat. Nenne den Pivot konkret.

Der Bericht muss die Persona-Passungs-Matrix, das stärkste überlebende Argument des Kill-Agenten (selbst unter VALIDIERT), den Assumption Graveyard (tragende Überzeugungen, die noch unbewiesen sind, jede mit ihrem günstigsten realen Test), eine Fix-Liste (≤6 Punkte: Schwäche → konkrete Maßnahme → Erfolgssignal) und die bewertete Rubrik enthalten – Bewertungen machen Wiederholungen vergleichbar, sodass der Benutzer nach dem Versand von Korrekturen /reality-check erneut ausführen und die Zahlen sich bewegen sehen kann, anstatt erneut über Stimmungen zu diskutieren.

Lieferformat. Präsentiere den vollständigen Bericht immer im Gespräch. Wenn ein Artefakt- oder Webseiten-Rendering-Tool verfügbar ist (z. B. Claude Codes Artefakt-Tool), rendere den Bericht AUCH als einzelne teilbare Seite: ein Urteilsbanner mit der Gesamtbewertung, die Bewertungstafel mit sichtbaren Schwellenwerten, die Persona-Passungs-Matrix, belegte Erkenntnisse – und einen Lösungsabschnitt, der jede Zeile der Fix-Liste zu einer implementierungsbereiten Sanierung erweitert: die Diagnose, die vorgeschriebene Änderung auf Datei-/Bildschirm-/Kopieebene, wen es entblockt und das Erfolgssignal. Erkenntnisse diagnostizieren; Lösungen verschreiben – das Artefakt muss beides enthalten, damit ein Teammitglied, das den Durchlauf nie gesehen hat, darauf reagieren kann. Kein Rendering-Tool → schreibe dieselbe Seite in eine lokale HTML/Markdown-Datei und teile dem Benutzer mit, wo sie sich befindet.

Beende mit der einzelnen wirkungsvollsten nächsten Aktion. Einer. Keine Liste von zwanzig.