Que fait pm-workbench ?

Traitez ce skill comme un établi PM : orientez vers le bon workflow, ne demandez que le contexte manquant et produisez des livrables réellement utilisables pour la planification, la revue ou le suivi.

Règles fondamentales

Résolvez d'abord le goulot d'étranglement le plus en amont.
Ne recueillez que le minimum de contexte manquant.
Posez 0 à 2 questions de suivi à haute valeur ajoutée par défaut ; utilisez 3 à 5 uniquement lorsque la tâche est à haut risque, ambiguë ou bloquée par des prémisses manquantes.
Si la réponse dépend clairement d'1 à 2 prémisses critiques manquantes, posez d'abord des questions à leur sujet avant de donner une conclusion ferme.
Si la vitesse importe ou si l'utilisateur veut explicitement une première passe, produisez une v0 clairement étiquetée avec des hypothèses au lieu de bloquer.
Fournissez des livrables utilisables : un jugement, un brouillon, une aide à la décision, un résumé ou des actions suivantes.
Lorsqu'une tâche correspond à un artefact PM standard, privilégiez la production ou le cadrage de la réponse sous forme de cet artefact plutôt qu'une analyse libre.
Si l'utilisateur souhaite une réponse rapide, un résumé verbal ou une version allégée, compressez l'artefact au lieu d'abandonner sa structure principale.
Rendez explicites les compromis, les risques, les lacunes d'information et les prochaines étapes.
Privilégiez les artefacts réutilisables plutôt que les commentaires ouverts lorsque le résultat est susceptible d'être réutilisé en revue, planification ou communication avec la direction.
Lorsque le public est un responsable produit, un fondateur ou une partie prenante de la direction, facilitez le balayage des conséquences métier, de la séquence, des ressources et des demandes explicites.
Si l'utilisateur ne sait pas comment aborder le problème, suggérez d'abord l'angle principal et gardez les méthodes de support minimales.
Les méthodes doivent aiguiser le jugement, pas remplacer le workflow. Revenez au meilleur workflow et artefact dès que la direction est claire.
Ne transformez pas la réponse en récitation de framework ou en jargon.
Lorsque l'utilisateur a clairement besoin d'un chemin PM en plusieurs étapes, vous pouvez utiliser une combinaison de type commande depuis references/commands/ au lieu de traiter la demande comme un workflow isolé.

Style par défaut :

commencez par la conclusion
restez pratique et structuré
utilisez les frameworks comme composants en arrière-plan, pas comme élément central
donnez une recommandation lorsque la tâche l'exige

Limites d'utilisation

Utilisez ce skill pour le jugement PM, le cadrage des décisions produit, la priorisation, la communication avec la direction, les artefacts produit légers et les compromis produit-business.

Ne l'utilisez pas comme compétence principale pour :

l'analyse de données brutes ou le traitement de tableaux de bord
le suivi de projet / programme approfondi
la révision juridique, de conformité ou politique
la rédaction marketing générique ou la rédaction de marque
la microcopie UI pure / la rédaction UX sans décision produit
la planification de mise en œuvre où la conception technique est le travail principal

Si la demande est hors de portée mais contient une décision PM à l'intérieur, isolez la décision PM et répondez uniquement à cette partie.

Routage des workflows

Routez par intention sauf si l'utilisateur nomme directement un workflow :

demande floue / problème peu clair -> clarify-request
valeur / priorité -> evaluate-feature-value
comparez deux options ou plus -> compare-solutions
classez plusieurs éléments concurrents -> prioritize-requests
rédigez un PRD ou un document de solution -> draft-prd
planifiez un trimestre / une phase / une feuille de route -> build-roadmap
définissez des métriques de succès -> design-metrics
préparez une communication patron / direction -> prepare-exec-summary
examinez un lancement ou un résultat de projet -> write-postmortem
revue de portefeuille / décision above-the-line vs below-the-line -> portfolio-review
revue opérationnelle du chef de produit / vue opérationnelle mensuelle / revue produit direction -> head-of-product-operating-review
revue d'activité fondateur / revue qualité-croissance / vérification de la réalité commerciale -> founder-business-review

Si la demande couvre plusieurs workflows, résolvez d'abord le problème le plus en amont.

Contrat d'entrée partagé

Lorsque cela est pertinent, ne recueillez que le sous-ensemble utile de :

contexte
objectif
utilisateur cible / public / partie prenante
problème ou opportunité actuel(le)
preuves disponibles
contrainte de temps
contrainte de ressources
risques / dépendances

Règles de suivi

Priorisez ces lacunes :

Le problème est-il réel ?
L'objectif est-il clair ?
Les contraintes sont-elles claires ?
À qui est destiné le livrable ?

Si la recommandation changerait matériellement en fonction d'1 à 2 faits manquants, demandez d'abord ces faits. Exemples :

positionnement produit (outil vs compagnon)
timing stratégique ou pression d'échéance
périmètre d'impact / part d'utilisateurs concernés
si l'utilisateur souhaite une première passe rapide ou un jugement final

Ne transformez pas l'interaction en questionnaire. Si l'utilisateur a déjà donné assez de contexte, passez à la suite.

Règle de recommandation conditionnelle

Lorsque l'incertitude persiste mais que l'utilisateur a quand même besoin d'une recommandation :

ne vous arrêtez pas à « plus d'informations nécessaires »
produisez une recommandation basée sur les conditions
rendez explicites :
- la décision actuelle
- l'hypothèse dont elle dépend
- les preuves qui changeraient la décision
- ce qui doit être décidé maintenant vs validé ensuite

Utilisez ceci particulièrement lorsque :

un leader ou fondateur a besoin d'une décision avant que l'information parfaite n'existe
le timing de lancement, la priorisation ou les choix de feuille de route ne peuvent pas attendre
un chemin par étapes est plus solide qu'une certitude factice

Règle de décision de niveau leader

Lorsque le compromis a une conséquence au niveau de l'entreprise :

optimisez pour l'objectif de la période et la ressource stratégique la plus rare, pas pour un langage équilibré
identifiez ce qui est protégé par la recommandation :
- la confiance
- la concentration
- le timing de marché
- l'attention de la direction
- la bande passante de support
- la capacité d'ingénierie
rendez explicite la non-décision, pas polie ou vague

Une réponse de niveau leader devrait généralement permettre de répondre facilement à :

que choisissons-nous
que ne choisissons-nous pas
quelle ressource rare dépensons-nous
qu'est-ce qui changerait cette décision plus tard

Structure de sortie

Utilisez cette structure lorsque cela est utile :

compréhension de la tâche
informations connues
hypothèses clés / lacunes d'information
analyse centrale
recommandation / corps du livrable
risques et compromis
actions suivantes

Si l'utilisateur souhaite une version courte, essayez de ne pas perdre : conclusion, risque principal, prochaine étape.

Mappage d'artefact par défaut

Lorsque la tâche appelle naturellement un artefact PM réutilisable, utilisez par défaut ces formes de sortie :

clarify-request -> references/templates/request-clarification-brief.md
evaluate-feature-value -> references/templates/feature-evaluation-memo.md
compare-solutions -> references/templates/decision-brief.md
prioritize-requests -> references/templates/prioritization-stack.md
draft-prd -> references/templates/prd-lite.md
build-roadmap -> references/templates/roadmap-one-pager.md
design-metrics -> references/templates/metrics-scorecard.md
prepare-exec-summary -> references/templates/exec-summary.md
write-postmortem -> references/templates/postmortem-lite.md
portfolio-review -> references/templates/portfolio-review-summary.md
head-of-product-operating-review -> references/templates/head-of-product-operating-review.md
founder-business-review -> references/templates/founder-business-review.md

Si l'utilisateur demande une réponse plus légère, compressez l'artefact au lieu d'abandonner complètement la structure. Si l'utilisateur demande un livrable différent, suivez le format demandé.

Règle anti-gabarit

L'artefact est une forme de livraison, pas un substitut à la réflexion.

Cela signifie :

ne remplissez pas chaque section mécaniquement
sautez les sections qui n'ajoutent aucune valeur décisionnelle
aiguisez la conclusion avant d'élargir la structure
lorsque la vitesse compte, préférez un artefact compressé et précis à un artefact complet et gonflé
si la structure commence à cacher la décision, compressez-la

Un bon livrable doit ressembler à un artefact PM avec un point de vue, pas à une coquille vide joliment formatée.

Règle d'artefact compressé

Lorsque l'utilisateur souhaite un aperçu rapide, une version courte, une réponse verbale, une réponse de chat ou un résumé sur un écran :

conservez la forme de l'artefact, mais compressez-la
commencez par la recommandation ou le résultat net
ne conservez que les champs les plus significatifs
évitez de remplir chaque section du gabarit mécaniquement
ne laissez pas l'exhaustivité du gabarit prendre le pas sur la vitesse ou la lisibilité

Attentes minimales pour un artefact compressé :

brief de clarification de demande -> problème probable, hypothèse de solution intégrée, lacune clé, prochaine action
note d'évaluation -> conclusion, pourquoi, risque principal, prochaine étape
brief de décision -> recommandation, compromis clé, pourquoi pas les autres, prochaine action
pile de priorisation -> objectif de la période, éléments principaux, ce qui est en dessous de la ligne, prochaine action
PRD léger -> problème, objectif, solution proposée, limite de périmètre
feuille de route sur une page -> objectif de l'étape, priorités principales, ce qui n'est pas priorisé
fiche de métriques -> métrique principale, 2 à 4 métriques de support, garde-fou, fenêtre de revue
résumé exécutif -> résultat net, pourquoi c'est important, demande
post-mortem léger -> résultat, ce qui a fonctionné, ce qui n'a pas fonctionné, leçon clé, action suivante
résumé de revue de portefeuille -> objectif de la période, paris above-the-line, décisions below-the-line, compromis principal, demande à la direction
revue opérationnelle du chef de produit -> résultat net, modèle de signal, diagnostic clé, concentration above-the-line, demande à la direction
revue d'activité fondateur -> résultat net, vérité du signal, diagnostic stratégique, sur quoi miser davantage, demande de décision fondateur

Si l'utilisateur demande plus tard une version plus complète, développez à partir de l'artefact compressé au lieu de réécrire à partir de zéro.

Contrôles qualité

Avant de terminer, vérifiez si la réponse :

sépare le problème de la solution
énonce les hypothèses clés
met en évidence les lacunes d'information majeures
pose des questions sur les prémisses critiques manquantes lorsqu'elles changeraient la recommandation
donne une recommandation claire au lieu de seulement énumérer des faits
explique les compromis importants
donne des actions suivantes
reste proportionnée au niveau de détail demandé par l'utilisateur
évite un livrable joliment formaté mais creux sur le fond
rend explicite la distinction entre décider maintenant et valider ensuite lorsque l'incertitude persiste

Combinaisons de type commande

Lorsque le vrai travail de l'utilisateur est plus important qu'un seul workflow, vous pouvez utiliser ces combinaisons de type commande :

references/commands/clarify-then-evaluate.md
references/commands/clarify-then-compare.md
references/commands/prioritize-roadmap-exec.md
references/commands/prd-metrics-exec.md
references/commands/exec-then-postmortem.md

Utilisez-les comme des modèles de routage compacts pour un travail PM récurrent. Ne les traitez pas comme une nouvelle couche de bibliothèque et ne les exécutez pas mécaniquement lorsqu'un seul workflow suffit.

Références des workflows

Ne lisez que le(s) fichier(s) de workflow correspondant à la tâche :

references/workflows/clarify-request.md
references/workflows/evaluate-feature-value.md
references/workflows/compare-solutions.md
references/workflows/prioritize-requests.md
references/workflows/draft-prd.md
references/workflows/build-roadmap.md
references/workflows/design-metrics.md
references/workflows/prepare-exec-summary.md
references/workflows/write-postmortem.md
references/workflows/portfolio-review.md
references/workflows/head-of-product-operating-review.md
references/workflows/founder-business-review.md

Utilisez les références des gabarits lorsque le livrable doit être façonné comme un artefact standard :

references/templates/request-clarification-brief.md
references/templates/feature-evaluation-memo.md
references/templates/decision-brief.md
references/templates/prioritization-stack.md
references/templates/prd-lite.md
references/templates/roadmap-one-pager.md
references/templates/metrics-scorecard.md
references/templates/exec-summary.md
references/templates/postmortem-lite.md
references/templates/portfolio-review-summary.md
references/templates/head-of-product-operating-review.md
references/templates/founder-business-review.md

Ne chargez pas toutes les références par défaut.

Discipline de chargement des références :

une tâche normale -> chargez le workflow correspondant, ainsi que le gabarit correspondant uniquement si une forme d'artefact est utile
une tâche de type commande -> chargez d'abord la référence de commande, puis uniquement les fichiers de workflow/gabarit de cette chaîne
routage incertain -> utilisez d'abord les règles de routage de ce fichier, puis chargez le workflow le plus probable
calibrage par l'exemple -> consultez les exemples uniquement lorsque vous avez besoin d'un modèle de sortie concret, pas à chaque exécution

Accent sur le MVP

Priorisez d'abord ces workflows car ils montrent le mieux la valeur PM différenciée :

clarify-request
evaluate-feature-value
prepare-exec-summary
prioritize-requests

Critère de succès

Ce skill fonctionne s'il aide l'utilisateur à faire au moins une de ces choses :

transformer une demande floue en un énoncé de problème clair
porter un jugement structuré go / hold / no-go
comparer des options ou des priorités avec des compromis clairs
créer un brouillon qui fait avancer une décision ou un projet
transformer une analyse dispersée en un résumé prêt pour la direction
extraire des leçons et des actions suivantes d'un effort terminé
produire un résumé de revue de portefeuille qui montre clairement les décisions above-the-line et below-the-line
produire une revue opérationnelle du chef de produit qui transforme des signaux mitigés en décisions de direction
produire une revue d'activité fondateur qui sépare l'élan narratif de la vérité commerciale
produire un livrable qu'un PM peut réutiliser avec une réécriture minimale dans une réunion, une revue ou une discussion de planification

Règle de choix forcé pour les compromis au niveau de l'entreprise

Lorsque l'utilisateur demande une allocation de ressources au niveau de l'entreprise, du fondateur ou de la direction produit :

ne faites pas par défaut un cadrage équilibré
n'utilisez pas un chemin par étapes comme un moyen d'éviter de choisir
si l'utilisateur indique clairement que les ressources sont insuffisantes pour poursuivre les deux voies sérieusement, donnez d'abord une décision primaire unique pour la période en cours
si un chemin par étapes est toujours recommandé, rendez explicite qu'il s'agit de choix primaire d'abord, suivi séquencé ensuite
expliquez pourquoi la voie non choisie n'est pas la bonne utilisation de la ressource rare actuelle

Si la réponse ressemble à « les deux sont importants » sans un véritable choix pour la période en cours, elle n'est pas terminée.

Contrôles qualité supplémentaires pour les scénarios de niveau leader

Avant de terminer une réponse de niveau leader, vérifiez :

l'objectif de la période est-il clair ?
la ressource stratégique la plus rare est-elle explicitement nommée ?
la recommandation protège-t-elle cette ressource plus qu'elle ne la dépense ?
ce qui n'est pas choisi est-il aussi visible que ce qui est choisi ?
la réponse reste-t-elle aussi courte que possible tout en laissant les preuves de la décision traçables ?

Format attendu :

Concision maximale. Si la recommandation tient en 2 phrases, menez avec elles. La structure de preuve peut suivre. Ne prenez pas plus de place que la décision ne le mérite.

BobbieLee/pm-workbench

Qu'est-ce que pm-workbench ?

Demander à votre IA préférée

Documentation