Product Lens

Product Lens — Think Before You Build

Diese Lane besitzt die Produktdiagnose, nicht das Schreiben implementierungsreifer Spezifikationen.

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

Wann verwenden

• Bevor Sie mit einem Feature beginnen – validieren Sie das „Warum“
• Wöchentliches Produktreview – bauen wir das Richtige?
• Wenn Sie zwischen Features wählen müssen
• Vor einem Launch – Sanity-Check der User Journey
• Wenn Sie eine vage Idee in ein Produktbriefing umwandeln, bevor die Engineering-Planung beginnt

Wie es funktioniert

Modus 1: Produktdiagnose

Wie YC-Bürozeiten, aber automatisiert. Stellt die harten Fragen:

1. Für wen ist das? (konkrete 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? (kleinste Sache, die die These beweist)
6. Was ist das Anti-Ziel? (was bauen Sie explizit NICHT?)
7. Woran erkennen Sie, 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, bauen“ ist, ist die nächste Lane product-capability, nicht mehr Founder-Theater.

Modus 2: Founder Review

Überprüft Ihr aktuelles Projekt durch die Founder-Brille:

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

Modus 3: User Journey Audit

Zeichnet die tatsächliche Benutzererfahrung auf:

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

Modus 4: Feature-Priorisierung

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

1. Alle Kandidatenfeatures auflisten
2. Jedes bewerten: Auswirkung (1-5) × Vertrauen (1-5) ÷ Aufwand (1-5)
3. Nach ICE-Score ordnen
4. Einschränkungen anwenden: Budget, Teamgröße, Abhängigkeiten
5. Ausgabe: priorisierte Roadmap mit Begründung

Ausgabe

Alle Modi liefern handlungsorientierte Dokumente, keine Aufsätze. Jede Empfehlung enthält einen konkreten nächsten Schritt.

Integration

Kombinieren mit:

• /browser-qa zur Überprüfung der User-Journey-Audit-Ergebnisse
• /design-system audit zur Bewertung der visuellen Politur
• /canary-watch für das Post-Launch-Monitoring
• product-capability, wenn das Produktbriefing zu einem implementierungsreifen Fähigkeitsplan werden soll