product-discovery

Présentation de product-discovery skill

À quoi sert product-discovery

La skill product-discovery aide un agent IA à mener une discovery produit structurée avant qu’une équipe n’engage du temps d’ingénierie. Elle est conçue pour valider des opportunités, cartographier les hypothèses à risque, planifier des sprints de discovery et décider s’il faut continuer, pivoter ou arrêter. Au lieu de demander de simples « idées produit », la skill oriente le travail vers des éléments probants : résultats attendus, opportunités, hypothèses, expérimentations et décisions d’apprentissage.

Cas d’usage idéal en Product Management

Utilisez product-discovery en Product Management lorsque vous avez besoin d’un workflow de discovery reproductible autour de problèmes clients encore flous, de paris sur de nouvelles fonctionnalités, d’expérimentations orientées marché ou de premiers concepts de solution. Elle est particulièrement utile aux product managers, fondateurs, product designers, UX researchers et équipes pluridisciplinaires qui veulent qu’un assistant IA structure des livrables de discovery, plutôt que de générer une roadmap générique.

Ce qui distingue cette skill

La skill s’appuie sur des frameworks de discovery très opérationnels : Opportunity Solution Trees, cartographie des hypothèses, Jobs-to-be-Done, Kano, logique de design sprint et planification d’expériences. Son principal élément différenciant est le script inclus scripts/assumption_mapper.py, qui peut prioriser des hypothèses depuis un CSV à partir de scores de risque et de certitude, puis suggérer des tests de validation adaptés à chaque catégorie d’hypothèse.

Quand ce n’est pas le bon outil

N’installez pas cette skill si votre besoin principal concerne la planification de delivery, le grooming de backlog de sprint, la mise en forme de PRD, la rédaction growth ou l’instrumentation analytics. product-discovery apporte le plus de valeur avant la delivery, lorsque l’équipe doit encore clarifier le problème utilisateur, identifier les croyances les plus risquées et choisir des méthodes de validation peu coûteuses.

Comment utiliser product-discovery skill

Installation de product-discovery et chemin du repository

Installez la skill depuis le chemin du repository GitHub utilisé par votre gestionnaire de skills. Une commande d’installation typique est :

npx skills add alirezarezvani/claude-skills --skill product-discovery

Le code source se trouve ici :

product-team/skills/product-discovery

Après l’installation, lisez d’abord SKILL.md, puis references/discovery-frameworks.md, et enfin scripts/assumption_mapper.py si vous prévoyez de scorer des hypothèses à partir d’un CSV. Le repository ne contient pas de README.md ni de metadata.json distincts dans ce dossier de skill ; les principales consignes d’utilisation sont donc concentrées dans ces trois fichiers.

Entrées nécessaires pour la skill

Pour un bon product-discovery usage, donnez à l’agent davantage qu’une simple demande de fonctionnalité. Incluez :

• Résultat cible : la métrique ou le comportement que vous voulez améliorer
• Segment utilisateur : qui rencontre le problème et dans quel contexte
• Données disponibles : interviews, tickets support, analytics, notes commerciales, raisons de churn
• Opportunité candidate : la douleur, le besoin ou le job to be done
• Contraintes : calendrier, capacité de l’équipe, conformité, marché, limites techniques
• Décision attendue : continuer, pivoter, arrêter, mener des interviews, prototyper ou concevoir une expérience

Prompt faible :

Help us validate a new onboarding feature.

Prompt plus solide :

Use product-discovery to plan discovery for reducing activation drop-off from 42% to 30% in 8 weeks. Segment: self-serve B2B admins setting up their first workspace. Evidence: 12 support tickets mention confusing permissions; analytics show most drop-offs happen before inviting teammates. We are considering an onboarding checklist but are unsure if the real opportunity is permissions clarity, team invitation anxiety, or lack of perceived value. Produce an Opportunity Solution Tree, risky assumptions, and a 1-week validation plan.

Workflow conseillé pour une première utilisation

Commencez par demander à la skill de définir un résultat mesurable et de construire un Opportunity Solution Tree : résultat → opportunités → idées de solution → expériences. Demandez-lui ensuite de distinguer les opportunités appuyées par des preuves des simples opinions internes. Générez ensuite les hypothèses de désirabilité, viabilité, faisabilité et utilisabilité. Enfin, transformez les hypothèses les plus risquées en interviews, tests de prototype, fake-door tests, tests de prix ou technical spikes.

Si vous avez déjà des hypothèses, créez un CSV avec les colonnes suivantes :

assumption,category,risk,certainty

Utilisez des valeurs de 0 à 1 pour risk et certainty, puis exécutez :

python3 scripts/assumption_mapper.py assumptions.csv

Le script priorise les hypothèses à fort risque et faible certitude, puis suggère un type de test de validation.

Modèles de prompts pratiques

Demandez des livrables exploitables pour décider, pas seulement des frameworks. Les bonnes demandes incluent :

• « Create an OST and mark which branches need more evidence. »
• « Turn these interview notes into opportunity themes and confidence levels. »
• « Map assumptions and identify the cheapest test for each top risk. »
• « Design a 1-week discovery sprint with daily evidence reviews. »
• « Define stop, pivot, and proceed criteria before we run tests. »

La skill fonctionne mieux si vous imposez des libellés de preuve explicites : comportement observé, citation directe, métrique, opinion interne ou inconnu.

FAQ sur product-discovery skill

product-discovery est-elle réservée aux product managers ?

Non. La product-discovery skill est pensée pour le Product Management, mais elle est aussi utile aux fondateurs, designers, researchers, équipes growth et tech leads impliqués dans la réduction des risques liés à des paris produit. La condition essentielle est de pouvoir fournir du contexte sur les clients, les objectifs business et les contraintes.

En quoi est-elle meilleure qu’un prompt de discovery classique ?

Un prompt classique peut produire une liste de questions ou d’expériences. product-discovery donne à l’agent un modèle de travail plus précis : résultat mesurable, Opportunity Solution Tree, catégories d’hypothèses, scoring risque/certitude, validation du problème, validation de la solution et décisions de sprint de discovery. Cette structure réduit les suppositions et rend les résultats plus faciles à comparer entre plusieurs opportunités.

Remplace-t-elle la recherche utilisateur ?

Non. Elle aide à planifier et synthétiser la discovery, mais elle ne remplace pas les interviews, les données comportementales, les tests de prototype ni les signaux de marché. Considérez ses résultats comme des hypothèses et des plans d’exécution. La qualité du résultat dépend fortement des preuves que vous fournissez et de la capacité de l’équipe à écarter les opportunités faibles.

Que lire en premier quand on débute ?

Commencez par SKILL.md pour comprendre le workflow, puis lisez references/discovery-frameworks.md pour les définitions des frameworks. Si vous débutez en discovery, concentrez-vous d’abord sur trois notions : Opportunity Solution Tree, cadrage d’interview Jobs-to-be-Done et matrice de priorisation des hypothèses. N’utilisez le script Python qu’après avoir compris ce que signifie chaque hypothèse.

Comment améliorer product-discovery skill

Améliorer les résultats de product-discovery avec de meilleures preuves

Le moyen le plus rapide d’améliorer les résultats de product-discovery est de fournir des preuves brutes, pas des conclusions déjà polies. Incluez des extraits d’interviews, des métriques comportementales, des tickets support, des raisons de pertes commerciales, des funnels d’usage ou des observations de prototypes. Demandez à l’agent de distinguer « preuve » et « interprétation » afin que votre équipe ne valide pas par accident une préférence interne.

Éviter les écueils fréquents

Les résultats faibles prennent souvent la forme d’arbres qui partent trop vite des solutions, d’hypothèses vagues, d’expériences surdimensionnées ou de plans d’interview qui posent des questions orientées. Pour les éviter, demandez explicitement :

• Les opportunités avant les solutions
• Des hypothèses formulées comme des affirmations testables
• La plus petite expérience crédible
• Des seuils de succès et d’échec
• La décision qui changera après le test

Par exemple, remplacez « users want better onboarding » par « new workspace admins fail to invite teammates because they do not understand permission consequences. »

Itérer après le premier résultat

Ne considérez pas le premier résultat comme définitif. Demandez à la skill de critiquer son propre plan de discovery selon le coût, la rapidité, la qualité des preuves et l’impact sur la décision. Puis demandez-lui de supprimer les expériences qui ne changent aucune vraie décision. Un prompt utile pour une deuxième passe :

Review this discovery plan. Identify assumptions that are too vague, experiments that are too expensive, and places where we are testing preference instead of behavior. Revise into a 5-day plan with clear proceed, pivot, and stop criteria.

Adapter la skill à votre équipe

Pour de meilleurs usages à long terme, ajoutez des exemples propres à votre équipe : vos métriques produit, segments clients, templates de recherche, standards d’expérimentation et seuils de décision. Si votre organisation a de fortes contraintes de conformité, des cycles de vente enterprise, des dynamiques de marketplace ou des contraintes hardware, incluez-les dans les prompts. product-discovery est plus efficace lorsque ses frameworks généraux sont ancrés dans votre environnement opérationnel réel.