Produktlinse

Produktlinse — Denk nach, bevor du baust

Diese Lane besitzt die Produktdiagnose, nicht das Schreiben von implementierungsreifen Spezifikationen.

Wenn der Benutzer ein dauerhaftes PRD-zu-SRS- oder Fähigkeitsvertrags-Artefakt benötigt, übergib an product-capability.

Wann verwenden

• Bevor Sie mit einer Funktion beginnen — validieren Sie das "Warum"
• Wöchentliche Produktüberprüfung — bauen wir das Richtige?
• Wenn Sie zwischen Funktionen wählen müssen
• Vor einem Launch — prüfen Sie die User Journey auf Plausibilität
• Wenn Sie eine vage Idee in ein Produktbriefing umwandeln, bevor die Engineering-Planung beginnt

Wie es funktioniert

Modus 1: Produktdiagnose

Wie YC-Sprechstunden, aber automatisiert. Stellt die harten Fragen:

1. Für wen ist das? (bestimmte Person, nicht "Entwickler")
2. Was ist der Schmerz? (quantifizieren: wie oft, wie schlimm, was tun sie heute?)
3. Warum jetzt? (was hat sich geändert, das dies möglich/nötig macht?)
4. Was ist die 10-Sterne-Version? (wenn Geld/Zeit unbegrenzt wären)
5. Was ist das MVP? (das kleinste Ding, das die These beweist)
6. Was ist das Anti-Ziel? (was baust du explizit NICHT?)
7. Woher weißt du, dass es funktioniert? (Metrik, nicht Bauchgefühl)

Ausgabe: ein PRODUCT-BRIEF.md mit Antworten, Risiken und einer Go/No-Go-Empfehlung.

Wenn das Ergebnis "Ja, baue das" ist, ist die nächste Lane product-capability, nicht mehr Gründer-Theater.

Modus 2: Gründerbewertung

Überprüft Ihr aktuelles Projekt durch die Linse eines Gründers:

1. README, CLAUDE.md, package.json, aktuelle Commits lesen
2. Ableiten: Was versucht das zu sein?
3. Bewerten: Product-Market-Fit-Signale (0-10)
   - Nutzungswachstumskurve
   - Retentionsindikatoren (wiederkehrende Mitwirkende, Rückkehrer)
   - Umsatzsignale (Preisseite, Abrechnungscode, Stripe-Integration)
   - Wettbewerbsvorsprung (was ist schwer zu kopieren?)
4. Identifizieren: das eine Ding, das dies 10x machen würde
5. Markieren: Dinge, die Sie bauen, die nicht wichtig sind

Modus 3: User-Journey-Audit

Zeichnet die tatsächliche Benutzererfahrung auf:

1. Das Produkt als neuer Benutzer klonen/installieren
2. Jeden Reibungspunkt dokumentieren (verwirrende Schritte, Fehler, fehlende Doks)
3. Jeden Schritt zeitlich messen
4. Mit der Einarbeitung des Wettbewerbers vergleichen
5. Bewerten: Time-to-Value (wie lange bis der Benutzer seinen ersten Erfolg hat?)
6. Empfehlen: Top 3 Fixes für die Einarbeitung

Modus 4: Funktionspriorisierung

Wenn Sie 10 Ideen haben und 2 auswählen müssen:

1. Alle Kandidatenfunktionen auflisten
2. Jede bewerten nach: Auswirkung (1-5) × Vertrauen (1-5) ÷ Aufwand (1-5)
3. Nach ICE-Punktzahl sortieren
4. Randbedingungen anwenden: Budget, Teamgröße, Abhängigkeiten
5. Ausgabe: priorisierte Roadmap mit Begründung

Ausgabe

Alle Modi geben handlungsorientierte Dokumente aus, keine Aufsätze. Jede Empfehlung hat einen spezifischen nächsten Schritt.

Integration

Kombinieren mit:

• /browser-qa zur Überprüfung der User-Journey-Audit-Ergebnisse
• /design-system audit für die visuelle Qualitätsbewertung
• /canary-watch für das Monitoring nach dem Launch
• product-capability, wenn das Produktbriefing in einen implementierungsreifen Fähigkeitsplan umgewandelt werden muss