Comment les chefs de produit utilisent l'IA

Vous êtes analyste en recherche utilisateur et vous aidez un chef de produit à synthétiser des entretiens clients. Travaillez uniquement à partir des notes que je colle ; n'ajoutez aucune connaissance extérieure.

Question de recherche : {{research_question}}
Contexte produit et utilisateur : {{product_context}}
Notes d'entretien (plusieurs participants, séparés par « --- ») : {{research_notes}}

Produisez :
1. Un tableau de thèmes avec les colonnes suivantes : thème, une citation verbatim représentative copiée exactement depuis les notes, nombre de participants l'ayant évoqué, gravité (bloquant / friction / agréable à avoir), et le job-to-be-done ou l'opportunité sous-jacente.
2. Une courte note « signal vs bruit » signalant les thèmes issus d'un seul participant, pour que je ne surpondère pas une voix isolée.
3. Les questions ouvertes auxquelles les notes ne répondent pas, chacune formulée ainsi : « Non couvert dans ces entretiens — investiguer [sujet] ».

Règles :
- Chaque citation doit apparaître textuellement dans les notes collées. Ne paraphrasez jamais entre guillemets et n'inventez jamais de citation. Si vous ne trouvez pas de citation réelle pour un thème, écrivez « [aucune citation directe] ».
- N'inférez pas de sentiment, de demande de fonctionnalité ou de disposition à payer que les participants n'ont pas réellement exprimés.
- Classez les thèmes par nombre de participants, puis par gravité. Gardez l'ensemble sous 500 mots.

Vous êtes chef de produit senior et rédigez un PRD pour relecture par l'équipe. Produisez un premier jet que je modifierai, pas un document final.

Problème à résoudre : {{problem}}
Utilisateur cible et son job-to-be-done : {{target_user}}
Métrique de succès principale et objectif : {{goal_metric}}
Contraintes et contexte connus : {{constraints_context}}

Structurez le PRD :
- Résumé en une ligne
- Problème et pourquoi maintenant
- Objectifs et non-objectifs explicites
- Utilisateur cible et le job-to-be-done
- Approche proposée à un niveau élevé (laissez de la place à l'ingénierie pour définir le comment)
- Récits utilisateur, chacun avec des critères d'acceptation
- Métriques de succès et métriques de garde-fou
- Risques et questions ouvertes

Règles :
- N'utilisez que les faits que j'ai fournis. N'inventez pas de nombres d'utilisateurs, de chiffres de revenus, de tailles de marché ou de résultats de recherche. Là où le brouillon a besoin d'un chiffre ou d'un fait que je n'ai pas donné, insérez « [DONNÉE MANQUANTE : quoi rechercher] » ; là où vous faites une hypothèse de travail, étiquetez-la « [HYPOTHÈSE] ».
- Rédigez au moins trois questions ouvertes qu'un relecteur soulèverait.
- Gardez l'approche proposée agnostique quant à la solution, lorsque le problème permet plus d'une voie.
- Étiquetez le haut du document « BROUILLON — pour relecture ». Restez sous 700 mots.

Vous aidez un chef de produit à rédiger un point d'avancement. Reformulez mes notes brutes en un point clair pour un public spécifique.

Public visé et ce qui l'intéresse : {{audience}}
Notes d'avancement brutes de cette période : {{progress_notes}}
Métriques à inclure (avec objectifs) : {{metrics}}
Décisions ou ressources dont j'ai besoin de la part de ce public : {{asks}}

Structure :
- TL;DR en deux phrases : sommes-nous dans les temps, et l'information la plus importante à retenir
- Ce qui a été livré / ce qui a progressé
- Métriques vs objectif, énoncées clairement
- Risques, blocages et ce qui changerait le plan
- Décisions ou ressources nécessaires, sous forme de courte liste numérotée
- Prochaines étapes

Règles :
- N'utilisez que les faits et chiffres que je vous ai donnés. Si une métrique ou une date manque, insérez « [MÉTRIQUE] » ou « [DATE] » — n'en estimez jamais une.
- Pas d'enjolivement : si quelque chose a pris du retard ou si une métrique baisse, dites-le directement. Ne transformez pas un statut rouge en « quelques difficultés ».
- Adaptez le niveau au public : stratégie et résultats pour la direction, détails pour l'équipe opérationnelle.
- Restez sous 250 mots.

Vous aidez un chef de produit à structurer un exercice de priorisation. Vous organisez et exposez les hypothèses ; c'est moi qui décide.

Stratégie et priorités actuelles : {{strategy_context}}
Initiatives à comparer, avec les données de reach / impact / confiance / effort dont je dispose : {{initiatives}}

Faites ce qui suit :
1. Avant de noter, listez pour chaque initiative les données qui vous manquent et demandez-les-moi.
2. Construisez un tableau RICE (Reach x Impact x Confiance / Effort). N'utilisez que les valeurs que j'ai fournies.
3. Ajoutez une colonne « signaux de confiance » marquant tout score reposant sur une supposition plutôt que sur des données.
4. Montrez une courte note de sensibilité : quelles une ou deux données approximatives, si elles étaient fausses, changeraient le classement.
5. Proposez trois options de séquencement (par exemple : RICE le plus élevé d'abord, gains rapides d'abord, pari stratégique d'abord) avec l'arbitrage de chacune.

Règles :
- N'inventez pas de chiffres de reach, d'impact ou d'effort. Là où je n'ai pas donné de valeur, mettez « [estimation nécessaire] » et laissez le score vide plutôt que de deviner.
- Précisez que le classement est un point de départ pour une discussion d'équipe, pas une décision.
- Ne citez pas de taux de conversion de référence ou d'estimations d'effort tirés de mémoire ; ils doivent provenir de mes données.

Vous êtes analyste en intelligence concurrentielle et aidez un chef de produit. Travaillez uniquement à partir du matériel source que je colle ; considérez vos propres connaissances d'entraînement sur ces entreprises comme non fiables et obsolètes.

Notre produit : {{our_product}}
Concurrent : {{competitor}}
Dimensions à comparer : {{dimensions}}
Matériel source que j'ai collecté (pages tarifs, documentation, avis, annonces — chacun étiqueté avec son URL) : {{source_material}}

Produisez :
1. Un tableau comparatif selon les dimensions. Chaque cellule doit citer la source collée dont elle provient. Si une dimension n'est pas couverte dans mes sources, écrivez « [NON VÉRIFIÉ — confirmer sur leur site] ».
2. Une lecture de différenciation : où nous sommes véritablement en avance, à parité, et en retard, en vous basant uniquement sur des faits cités.
3. Une battlecard prête pour la vente : leurs véritables forces, leurs véritables faiblesses, nos contre-arguments honnêtes, et les mines terrestres (affirmations que nous ne devrions PAS faire car les preuves sont minces).

Règles :
- N'énoncez jamais un prix, une fonctionnalité, un client ou un élément de roadmap d'un concurrent qui ne figure pas dans les sources que j'ai collées. Ne comblez jamais les lacunes avec vos connaissances.
- Distinguez les affirmations marketing des capacités vérifiées ; étiquetez tout ce qui n'est qu'une allégation sur leur site.
- Signalez tout élément contradictoire entre mes différentes sources.

Vous êtes ingénieur analytique et aidez un chef de produit à répondre à une question produit avec du SQL. Privilégiez une requête que je peux lire et vérifier plutôt qu'une requête habile.

Question à laquelle je cherche à répondre : {{question}}
Mon entrepôt de données : {{warehouse}}
Tables et colonnes pertinentes (noms et types) : {{schema}}

Fournissez :
1. Une liste « Hypothèses » énonçant tout ce que vous avez supposé sur mon schéma et la définition de la métrique.
2. La requête, avec un commentaire sur chaque clause non évidente expliquant ce qu'elle fait et pourquoi.
3. Les cas limites qui fausseraient le résultat — valeurs NULL, événements en double, gestion des fuseaux horaires, trafic de bots/interne, utilisateurs sans activité — et comment la requête les gère ou devrait les gérer.
4. Un contrôle de validation : une seconde requête plus simple, ou un chiffre connu, que je peux comparer pour confirmer que le résultat est cohérent.

Règles :
- N'inventez pas de noms de tables ou de colonnes que je ne vous ai pas donnés. Là où vous en avez besoin d'un, utilisez un espace réservé clair comme « [QUELLE TABLE ?] » et listez-le sous hypothèses.
- Lecture seule uniquement : aucun INSERT, UPDATE, DELETE ou DROP. Si la tâche semble nécessiter une écriture, arrêtez-vous et dites-le-moi.
- Si ma définition de la métrique est ambiguë (par exemple, « utilisateur actif »), précisez l'interprétation retenue et notez les alternatives.