Où l'IA a vraiment sa place dans la semaine d'un PM
Le product management, c'est quatre métiers différents qui partagent un seul agenda. Vous lisez beaucoup (retours, tickets, transcriptions, exports analytics), vous écrivez beaucoup (specs, mises à jour, briefs), vous analysez un peu (funnels, cohortes, résultats d'enquêtes), et vous persuadez sans arrêt. Chacune de ces tâches récompense un modèle différent, ce qui explique pourquoi un seul abonnement IA couvre environ deux tiers du travail et laisse le reste ressembler à une lutte.
| Tâche du PM | Meilleur modèle | Pourquoi |
|---|---|---|
| Narratif de PRD, énoncés de problème, mises à jour produit | Claude | Tient un raisonnement long, écrit une prose qu'un ingénieur lira vraiment |
| Catégorisation des retours, regroupement de tickets, extraction structurée | GPT | Fiable sur des formats de sortie stricts et des libellés de catégorie cohérents |
| Recherche de discovery, analyses concurrentielles, contexte marché | Gemini | Le meilleur sur le contenu web récent, renvoie des sources que vous pouvez ouvrir |
| Longues transcriptions, dossiers de recherche, rapports de 100 pages | Gemini | Fenêtre de contexte de 1M tokens, donc tout le corpus tient en un seul passage |
| Critique de spec et chasse aux cas limites | N'importe quel modèle qui n'a pas écrit la spec | Un lecteur indépendant repère ce que l'auteur ne peut pas voir |
Rien de tout cela ne remplace le jugement sur ce qu'il faut construire. Cela réduit la distance entre disposer des informations et avoir quelque chose d'écrit, ce qui est là où la plupart des semaines de PM perdent réellement du temps. Le changement de modèle coûte peu, aussi : sur Whizi Pro, un message Claude Sonnet 5 dépense 10 crédits d'une allocation mensuelle de 2 000 crédits, une extraction GPT-5.6 Luna en dépense 1, et Gemini 3.7 Flash lit les transcriptions à 2 crédits par message.
Rédiger un PRD que l'ingénieur ne renverra pas
La plupart des specs écrites par l'IA échouent sur la même chose : elles décrivent une fonctionnalité plutôt qu'une décision. L'ingénierie n'a pas besoin d'un paragraphe sur l'importance du client. Elle a besoin des états, des cas limites, et de ce qui se passe quand l'appel échoue. Demandez cela explicitement et le résultat change de nature.
Prompt : l'énoncé du problème d'abord
Rédige la section énoncé du problème d'un PRD. Preuves dont je dispose : [colle les tickets de support, l'analytics, les citations d'entretien]. Ne propose pas de solution. Retourne : qui a le problème, à quelle fréquence, ce qu'ils font actuellement à la place, ce que cela leur coûte, et ce qu'on attendrait de voir changer si c'était résolu. Marque toute affirmation non soutenue par les preuves collées comme HYPOTHÈSE.
Prompt : le corps de la spec
Transforme ceci en spécification pour une équipe d'ingénierie. Fonctionnalité : [description]. États utilisateur à couvrir : [liste]. Retourne : des user stories avec critères d'acceptation, chaque état y compris vide, chargement, erreur et accès refusé, le comportement quand une dépendance est indisponible, les événements analytics avec leurs propriétés, et les questions ouvertes. N'invente aucune exigence que je n'ai pas énoncée. Liste tout ce que tu as dû supposer dans une section séparée à la fin.
Prompt : la passe de critique
Agis comme un ingénieur senior qui relit cette spec avant l'estimation. Liste uniquement les problèmes : comportement non défini, états manquants, exigences en conflit, travail de migration caché, et tout ce qui produira une question de suivi lors du refinement. Ne réécris pas la spec.
Exécutez ce troisième prompt dans un modèle qui n'a pas écrit la spec. Il fait remonter de façon fiable les trois questions que votre équipe soulèverait sinon en refinement, et y répondre à l'avance fait la différence entre une session de grooming de 20 minutes et une de 50 minutes.
Transformer des retours bruts en quelque chose de priorisable
La tâche IA à plus fort levier en product management n'est pas l'écriture. C'est lire 400 retours clients sous une forme exploitable. Fait manuellement, c'est une demi-journée. Bien fait avec un modèle, c'est 20 minutes, et la qualité dépend presque entièrement du fait de forcer des catégories stables.
Prompt : première passe de catégorisation
Voici des retours clients bruts. Regroupe-les en thèmes. Pour chaque thème, retourne : un libellé, le nombre d'éléments, la sévérité impliquée par le langage, une citation verbatim représentative copiée exactement, et si le thème est un bug, une capacité manquante, un problème d'utilisabilité, ou un décalage d'attente. Ne fusionne pas des thèmes ayant des causes racines différentes même si le libellé se ressemble. Ne paraphrase pas les citations. Retours : [colle ici].
Prompt : seconde passe sur une taxonomie fixe
Reclasse les mêmes retours en utilisant uniquement ces catégories : [colle ta taxonomie existante]. Tout ce qui ne rentre pas va dans NON CLASSÉ avec une explication. Retourne un tableau de catégorie, nombre, et pourcentage.
La structure en deux passes compte. La première passe vous dit ce qu'il y a réellement dans les données. La seconde rend le résultat comparable au trimestre précédent, ce qui le rend exploitable dans une conversation de priorisation plutôt que simplement intéressant.
| Ce qu'il faut demander | Ce que vous obtenez | À quoi c'est utile |
|---|---|---|
| Thèmes avec comptages | Une liste classée des zones de problème | Input roadmap, planification trimestrielle |
| Citations verbatim uniquement | Le langage client non édité | Copywriting, positionnement, persuasion des dirigeants |
| Répartition sévérité et fréquence | Un 2x2 de la douleur contre le volume | Décider quoi corriger en premier |
| Contradictions | Où des segments veulent des choses opposées | Détecter tôt un faux consensus |
Cette dernière ligne mérite un prompt permanent : Où dans ces retours des utilisateurs différents veulent-ils des choses incompatibles ? Nomme les segments et l'arbitrage. Une liste de thèmes aplatit le désaccord, et le désaccord est généralement la chose la plus utile dans les données.
Narratif exécutif et communications de lancement
Le même contenu doit exister à quatre altitudes : une spec pour l'ingénierie, une mise à jour pour l'équipe, un paragraphe pour la revue de direction, et une note de lancement pour les clients. Réécrire entre les altitudes est le travail le plus mécanique du métier et le plus facile à déléguer.
Prompt : changement d'altitude
Réécris ceci pour [audience]. Ils se soucient de [préoccupations spécifiques]. Ils ont [niveau] de contexte sur ce domaine produit. Garde chaque affirmation factuelle identique. Longueur : [contrainte]. Commence par la décision ou le résultat, pas par le contexte. Brouillon : [colle ici].
Prompt : le paragraphe de direction
Compresse cette mise à jour en 120 mots pour un dirigeant qui la lira une seule fois. Structure : ce qui a changé, ce que cela signifie pour la métrique sur laquelle on s'est engagé, ce dont on a besoin de leur part, et le seul risque qui mérite leur attention. Aucun adjectif qui ne soit pas mesuré.
Prompt : le pré mortem
Suppose que ce lancement a échoué dans six mois. Écris les trois explications les plus plausibles, classées par probabilité, en utilisant uniquement ce qui figure dans le plan ci-dessous. Pour chacune, indique le signal précoce qu'on pourrait surveiller. Plan : [colle ici].
Gardez les quatre altitudes dans le même fil Whizi. La note de lancement hérite du contexte de la spec et de l'analyse des retours, si bien que vous arrêtez de réexpliquer la fonctionnalité à chaque changement d'audience.
Où l'IA induit spécifiquement les product managers en erreur
Trois modes d'échec comptent plus dans ce métier que dans la plupart des autres.
Verbatims fabriqués. Si vous demandez des citations représentatives sans ancrer le modèle au texte source, vous obtiendrez parfois une phrase plausible qu'aucun client n'a dite. Demandez toujours de copier les citations exactement, sans paraphraser, et vérifiez-en trois par rapport aux données brutes avant qu'une citation n'atteigne une diapositive.
Fausse confiance issue de petits échantillons. Un modèle catégorisera huit tickets de support avec exactement la même assurance qu'il en catégorise huit cents. Demandez des comptages pour chaque thème, et traitez tout ce qui est en dessous d'une poignée d'occurrences comme une observation plutôt qu'un signal.
Théâtre de roadmap. Demander à un modèle de prioriser votre backlog produit un classement confiant dérivé de rien d'autre que des mots de vos tickets. Il n'a aucun accès à votre stratégie, votre capacité, votre dette technique, ou l'affaire qui se conclut le trimestre prochain. Utilisez-le pour structurer l'arbitrage, jamais pour trancher.
- Enregistrez un modèle de prompt de PRD dans Claude et un prompt de critique à exécuter dans un autre modèle
- Enregistrez un modèle de catégorisation des retours dans GPT avec votre taxonomie existante collée
- Enregistrez un modèle d'analyse concurrentielle dans Gemini qui exige une URL pour chaque affirmation
- Demandez toujours des comptages à côté des thèmes, et traitez les petits comptages comme des observations
- Demandez au modèle de copier les verbatims exactement, puis vérifiez-en trois par rapport à la source
- Faites un pré mortem sur chaque plan de lancement avant la revue de lancement, pas après
- Gardez la spec, les retours et les communications de lancement dans un seul fil pour que le contexte se transmette
Questions fréquentes
Puis-je coller des entretiens clients ?
Oui. Pour les longues transcriptions, utilisez Gemini : sa fenêtre de contexte de 1M tokens contient environ 2 000 pages de texte, donc un ensemble complet d'entretiens tient en un seul passage plutôt que d'être découpé. Retirez d'abord les noms, emails et identifiants d'entreprise. Les rôles et les segments sont tout ce dont l'analyse a besoin, et retirer le reste vous garde à l'écart de la plupart des politiques de données internes.
Est-ce que Whizi s'intègre à Jira ou Linear ?
Pas nativement pour l'instant. En pratique, le workflow consiste à générer la sortie structurée dans Whizi (user stories avec critères d'acceptation, un tableau de thèmes avec comptages) et à la coller dans votre outil de suivi, ce qui prend quelques secondes car le format est déjà celui attendu par l'outil. Demandez la sortie sous forme de tableau Markdown ou d'un ticket par bloc si vous voulez les coller individuellement.
Quel modèle écrit le meilleur PRD ?
Claude pour les sections narratives, c'est à dire l'énoncé du problème, la justification, et tout ce dont un humain doit être convaincu. GPT pour les sections structurées, c'est à dire les user stories, les critères d'acceptation, les tableaux d'états, et les définitions d'événements analytics. Répartir le document entre les deux prend un changement de modèle en plus et réduit sensiblement la passe d'édition.
Est-ce sûr de coller une roadmap interne ou des données de revenu ?
Whizi n'entraîne pas ses modèles sur vos conversations, et la politique de données de chaque fournisseur est disponible avant d'activer ce modèle. La politique de votre entreprise est généralement la contrainte la plus stricte. Une bonne habitude consiste à indexer les chiffres sensibles plutôt qu'à coller des valeurs absolues, puisque l'analyse du mouvement relatif fonctionne de façon identique et que les chiffres cessent d'être sensibles.
L'IA peut-elle prioriser mon backlog ?
Elle peut structurer l'arbitrage, ce qui est réellement utile : noter les éléments selon des critères que vous définissez, faire apparaître où deux éléments dépendent l'un de l'autre, et montrer quels segments un choix donné dessert. Elle ne peut pas trancher, car elle n'a aucune visibilité sur votre stratégie, la capacité de votre équipe, ou le contexte commercial. Traitez tout classement qu'elle produit comme un point de départ à la discussion.