lentille-produit

Product Lens — Réfléchissez avant de construire

Cette voie s'occupe du diagnostic produit, pas de la rédaction de spécifications prêtes pour l'implémentation.

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

Quand l'utiliser

• Avant de commencer toute fonctionnalité — valider le « pourquoi »
• Revue produit hebdomadaire — construisons-nous la bonne chose ?
• Lorsqu'on est bloqué entre plusieurs fonctionnalités
• Avant un lancement — vérifier le parcours utilisateur
• Lorsqu'on convertit une idée vague en brief produit avant le début de la planification technique

Comment ça marche

Mode 1 : Diagnostic produit

Comme les heures de bureau YC mais automatisé. Pose les questions difficiles :

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

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

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

Mode 2 : Revue fondateur

Révise votre projet actuel avec un regard de fondateur :

1. Lire README, CLAUDE.md, package.json, les commits récents
2. Inférer : qu'est-ce que cela essaie d'être ?
3. Noter : signaux d'adéquation produit-marché (0-10)
   - Tendance de croissance d'utilisation
   - Indicateurs de rétention (contributeurs récurrents, utilisateurs de retour)
   - Signaux de revenu (page de tarification, code de facturation, intégration Stripe)
   - Fossé concurrentiel (qu'est-ce qui est dur à copier ?)
4. Identifier : la seule chose qui multiplierait par 10 ce projet
5. Signaler : 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, docs manquantes)
3. Chronométrez chaque étape
4. Comparez avec l'intégration des concurrents
5. Notez : le temps pour obtenir de la valeur (combien de temps jusqu'à ce que l'utilisateur obtienne sa première victoire ?)
6. Recommandez : les 3 principales corrections 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 : trésorerie, taille de l'équipe, dépendances
5. Sortie : feuille de route priorisée avec justification

Sortie

Tous les modes produisent des documents exploitables, pas des essais. Chaque recommandation a une étape suivante spécifique.

Intégration

Associer avec :

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