Constructeur d'Étude de Cas PM
Ce que fait ce skill
Prend une initiative produit sur laquelle l'utilisateur a travaillé — à n'importe quel stade d'achèvement, avec ou sans métriques polies — et construit une étude de cas structurée et convaincante qui démontre la réflexion d'un chef de produit. Le but n'est pas d'écrire du texte marketing. C'est de mettre en lumière les décisions qui ont été difficiles, le contexte qui les a rendues difficiles, et le résultat qui en a découlé.
Une bonne étude de cas montre comment un PM pense, pas seulement ce qu'il a livré.
Étape 1 : Recueillir la matière première
Demandez ce qui suit en une seule invite. Si quelque chose est déjà dans le contexte, ne le demandez pas. Des informations imparfaites sont acceptables — vous travaillerez avec ce qui est fourni et signalerez les lacunes plutôt que de bloquer sur elles.
- L'initiative — Sur quoi avez-vous travaillé ? (Fonctionnalité, produit, plateforme, refonte, projet 0→1, projet stratégique, annulation, etc.)
- Contexte et contraintes — Quelle entreprise, quelle étape, quelle taille d'équipe ? Quelles contraintes importaient (calendrier, ressources, dette technique, dynamiques organisationnelles) ?
- Le problème que vous résolviez — Qu'est-ce qui était cassé, manquant, ou flou ? De qui était-ce le problème ?
- Ce que vous avez fait — Les décisions clés que vous avez prises, les approches que vous avez envisagées, le travail que vous avez dirigé
- Le résultat — Qu'est-ce qui a été livré ? Qu'est-ce qui a changé ? Des métriques, même approximatives ?
- Ce que vous feriez différemment — Optionnel, mais rend l'histoire plus crédible
- Où cela sera utilisé — Site portfolio, entretien, LinkedIn, document interne, échantillon d'écriture ?
Une fois que vous avez cela, continuez. N'attendez pas des informations parfaites.
Étape 2 : Identifier la colonne vertébrale narrative
Avant d'écrire, identifiez la structure narrative qui fait fonctionner cette étude de cas. Toute étude de cas PM solide a :
- Le problème qui mérite qu'on s'y intéresse — Pourquoi cela importait-il ? Qui était concerné ?
- La décision non évidente — Le moment où plusieurs chemins raisonnables existaient et où le jugement était requis. C'est le cœur de l'étude de cas.
- La contrainte qui a tout façonné — Qu'est-ce qui a rendu cela difficile ? (Dette technique, désalignement des parties prenantes, données ambiguës, calendrier serré, priorités concurrentes)
- Le résultat qui prouve quelque chose — Pas seulement « nous l'avons livré », mais ce qui a changé dans le monde
Nommez ces quatre éléments explicitement avant d'écrire. Si vous ne trouvez pas de « décision non évidente », demandez à l'utilisateur : « Quelle a été la décision la plus difficile que vous ayez prise ? » C'est généralement la vraie histoire.
Étape 3 : Rédiger l'étude de cas complète
Structure :
[Titre de l'initiative]
Phrase d'accroche : ce que c'était et ce que cela a changé
Le problème
Qu'est-ce qui était cassé ou manquant ? Le problème de qui ? Comment saviez-vous que c'était un vrai problème qui méritait d'être résolu ? (2 à 4 phrases. Résistez à l'envie de commencer par le contexte de l'entreprise.)
Contexte
Avec quoi travailliez-vous ? Taille de l'équipe, stade du produit, contraintes qui importaient. Restez concis — seulement le contexte qui explique pourquoi les décisions étaient difficiles.
Ce que j'ai fait
Récit des décisions clés, pas une liste d'activités. Structurez-le comme une histoire : ce que vous avez essayé, ce que vous avez appris, ce que vous avez changé, ce que vous avez décidé.
Incluez :
- La décision la plus difficile et le raisonnement qui la sous-tend
- Ce que vous avez envisagé et écarté
- Comment vous avez géré l'incertitude ou les signaux contradictoires
- Avec qui vous avez travaillé et pourquoi cela importait
N'incluez pas :
- Tout ce qui s'est passé (c'est un point fort, pas un journal)
- Les étapes de processus qui n'ont pas nécessité de jugement (« J'ai animé les mêlées quotidiennes »)
- Le langage de contribution (« J'ai soutenu l'équipe dans... »)
Le résultat
Ce qui a été livré. Ce qui a changé. Des métriques si disponibles — des vraies, pas des chiffres de vanité. Si vous n'avez pas de métriques, décrivez quel changement observable s'est produit.
Ce que je ferais différemment
Une observation honnête. Rend l'histoire réelle et signale un PM qui apprend. Sautez si l'utilisateur préfère.
Étape 4 : Produire les formats de sortie
Après avoir rédigé l'étude de cas complète, produisez deux versions supplémentaires :
Version article LinkedIn (600 à 900 mots)
Même structure, prose plus serrée. Commence par le « alors quoi » — l'insight ou la décision qui a rendu le projet intéressant — pas par le contexte. Termine par une conclusion claire ou une question ouverte. Approprié pour publication sur LinkedIn.
Plan de points de discussion (pour narration orale)
Un plan structuré que l'utilisateur peut internaliser pour des entretiens ou des présentations de portfolio :
- Phrase d'accroche d'une phrase : « C'était un [type de problème] chez [entreprise] dans le contexte de [contexte] »
- La décision non évidente : ce que c'était, ce que vous avez envisagé, ce que vous avez décidé
- Le résultat : ce qui s'est passé
- La leçon : ce que vous feriez différemment ou ce que cela vous a appris
Étape 5 : Proposer des améliorations
Après avoir livré les trois formats, proposez :
« Voulez-vous que j'ajuste l'angle, resserre une section, affine le cadrage des métriques, ou adapte cela pour un rôle ou une entreprise spécifique ? Dites-moi ce qui doit changer. »
Améliorations courantes :
- Adaptation pour un rôle spécifique — Re-cadrer les décisions à mettre en avant en fonction de ce qui importe à l'entreprise cible
- Coaching sur les métriques — Aider l'utilisateur à déterminer quels chiffres il peut réellement revendiquer, et comment les présenter honnêtement s'ils sont partiels ou indirects
- Resserrement pour un portfolio — Réduire au récit essentiel pour une présentation de portfolio de 2 minutes
- Renforcement du récit de décision — Si l'étude de cas ressemble à une annonce de fonctionnalité, la reformuler autour des appels de jugement
Consignes de ton et de voix
La voix par défaut pour les études de cas :
- Première personne, active — « J'ai décidé de... » pas « L'équipe a décidé de... »
- Spécifique sur les décisions — Nommez le compromis, pas seulement le résultat
- Honnête quant à l'incertitude — « Nous ne savions pas X, donc nous avons... » est plus fort que de prétendre que tout était planifié
- Épurée — Une idée par phrase. Supprimez les préambules.
- Pas de jargon — « Nous avons amélioré la rétention » pas « Nous avons stimulé l'engagement des utilisateurs grâce à une optimisation de l'intégration sans friction »
Si l'utilisateur a sa propre voix, adaptez-vous. Demandez un échantillon d'écriture s'il souhaite un style spécifique.
Ce qui rend une étude de cas PM forte vs faible
Forte :
- Centrée sur une décision, pas sur une fonctionnalité
- Nomme ce qui était difficile et pourquoi
- A un résultat spécifique, même imparfait
- Montre le jugement : ce qui a été envisagé et écarté
- Se lit comme une personne, pas comme une description de poste
Faible :
- Commence par le contexte de l'entreprise avant le problème
- Décrit les étapes du processus sans expliquer pourquoi elles importaient
- Saute la décision difficile — dit simplement « nous avons livré X et cela a fonctionné »
- Métriques génériques (« amélioration du NPS ») sans contexte
- Voix passive tout au long (« l'équipe a pu... »)
Si la matière première que l'utilisateur vous donne produirait une étude de cas faible, nommez la lacune et posez la bonne question pour débloquer la vraie histoire.