Product Lens

Product Lens — Réfléchissez avant de construire

Cette compétence gère le diagnostic produit, pas la rédaction de spécifications prêtes à l'implémentation.

Si l'utilisateur a besoin d'un artefact durable PRD-vers-SRS ou d'un contrat de capacité, passez à product-capability.

Quand l'utiliser

• Avant de démarrer toute fonctionnalité — validez le « pourquoi »
• Revue produit hebdomadaire — construisons-nous la bonne chose ?
• Quand vous êtes bloqué entre plusieurs fonctionnalités
• Avant un lancement — vérification de l'expérience utilisateur
• Quand vous transformez une idée vague en brief produit avant la planification technique

Comment ça fonctionne

Mode 1 : Diagnostic produit

Comme des permanences de YC mais automatisé. Pose les questions difficiles :

1. À qui cela s'adresse-t-il ? (personne spécifique, pas « développeurs »)
2. Quel est le problème ? (quantifiez : à quelle fréquence, à quel point, que font-ils aujourd'hui ?)
3. Pourquoi maintenant ? (qu'est-ce qui a changé pour rendre cela possible/nécessaire ?)
4. Quelle est la version 10 étoiles ? (si l'argent/temps étaient illimités)
5. Quel est le MVP ? (la plus petite chose qui prouve la thèse)
6. Quel est l'anti-objectif ? (que ne construisez-vous PAS explicitement ?)
7. Comment savez-vous que ça marche ? (métrique, pas des impressions)

Sortie : un PRODUCT-BRIEF.md avec les réponses, les risques et une recommandation go/no-go.

Si le résultat est « oui, construisez ceci », la prochaine compétence est product-capability, pas plus de théâtre de fondateur.

Mode 2 : Revue fondateur

Examine votre projet actuel à travers le prisme d'un fondateur :

1. Lisez README, CLAUDE.md, package.json, les commits récents
2. Inférez : qu'est-ce que cela essaie d'être ?
3. Notez : signaux d'adéquation produit-marché (0-10)
   - Trajectoire de croissance d'utilisation
   - Indicateurs de rétention (contributeurs récurrents, utilisateurs qui reviennent)
   - Signaux de revenus (page de tarification, code de facturation, intégration Stripe)
   - Fossé concurrentiel (qu'est-ce qui est difficile à copier ?)
4. Identifiez : la chose qui décuplerait ce projet
5. Signalez : les choses que vous construisez qui n'ont pas d'importance

Mode 3 : Audit du parcours utilisateur

Cartographie l'expérience utilisateur réelle :

1. Clonez/installez le produit en tant que nouvel utilisateur
2. Documentez chaque point de friction (étapes confuses, erreurs, documentation manquante)
3. Chronométrez chaque étape
4. Comparez avec l'intégration des concurrents
5. Notez : temps avant valeur (combien de temps avant que l'utilisateur obtienne sa première réussite ?)
6. Recommandez : les 3 correctifs prioritaires pour l'intégration

Mode 4 : Priorisation des fonctionnalités

Quand vous avez 10 idées et devez en choisir 2 :

1. Listez toutes les fonctionnalités candidates
2. Notez chacune sur : impact (1-5) × confiance (1-5) ÷ effort (1-5)
3. Classez par score ICE
4. Appliquez les contraintes : runway, taille de l'équipe, dépendances
5. Sortie : feuille de route priorisée avec justification

Sortie

Tous les modes produisent des documents actionnables, pas des dissertations. Chaque recommandation comporte une étape suivante spécifique.

Intégration

Associez avec :

• /browser-qa pour vérifier les conclusions de l'audit du parcours utilisateur
• /design-system audit pour une évaluation du polish visuel
• /canary-watch pour la surveillance post-lancement
• product-capability quand le brief produit doit devenir un plan de capacité prêt pour l'implémentation