Guide de travail standard du PM
Pour chaque PM de notre équipe produit, que vous maîtrisiez la technique ou non. Ce guide a un objectif : vous faire passer de « je n'ose pas, je ne sais pas l'utiliser » à « je ne peux plus m'en passer ».
Avant tout : n'ayez pas peur, lancez-vous
Si votre sentiment actuel vis-à-vis de Claude Code est « j'entends que c'est puissant, mais je ne sais pas par où commencer », c'est tout à fait normal. Commençons par dissiper trois idées reçues.
Idée reçue n° 1 : je ne connais pas le code, je ne peux pas l'utiliser
Faux — et même tout l'inverse : ne pas maîtriser la technique est un avantage. Vous n'êtes pas paralysé par "à quel point c'est difficile à implémenter" — vous vous concentrez uniquement sur ce que vous voulez exprimer clairement. Et exprimer clairement une idée est précisément le cœur de métier du PM. L'avenir, c'est « Dites-le, l'IA le construit » : une phrase, et l'IA vous le fabrique.
Idée reçue n° 2 : je vais tout casser, provoquer des dégâts
Faux. Dans votre propre répertoire de projet, vous pouvez tout essayer sans risque. Dans le pire des cas, le résultat ne convient pas et vous dites « ce n'est pas ça, recommence ».
Idée reçue n° 3 : c'est un outil que je dois apprendre à "utiliser"
Changez de perspective : ce n'est pas un outil, c'est un collaborateur. Un stagiaire polyvalent infatigable, disponible à toute heure, capable de tout faire un peu. Il vous suffit de lui confier des tâches avec la même clarté qu'à une vraie personne.
Première étape : dialoguer en 5 minutes
Pas besoin d'apprendre de commandes. Entrez dans le dossier du projet et parlez naturellement. L'essentiel tient en trois formules.
Commencer par le plus simple
Crée-moi une page web avec le titre "Bonjour", fond bleu clair, puis lance un serveur local pour que je puisse la voir dans le navigateur.
La page apparaît dans le navigateur = félicitations, vous savez déjà l'utiliser.
Les trois formules clés
- « Fais-moi… » — confier une tâche
- « Là ce n'est pas bon, ça devrait être… » — donner un retour
- « Avant de commencer, pose-moi quelques questions » — le laisser vous aider à clarifier
Principes fondamentaux : quatre prémisses
| Prémisse | Signification |
|---|---|
| Pas besoin de coder, mais savoir décrire | C'est le traducteur « idée → produit fini » — plus c'est clair, plus c'est précis. |
| Accessible à tous, à différents niveaux | Pas de barrière à l'entrée, seulement une courbe de maîtrise. |
| Prototype = quelque chose qui tourne vraiment | Cliquable, interactif, testable par de vrais utilisateurs — pas une image statique. |
| Toute l'équipe bascule ensemble | Nouveau mode de travail par défaut, pas une expérience personnelle. |
Workflow en cinq phases (décomposition détaillée)
Le travail du PM découpé en cinq phases. Pour chacune : objectif, comment le formuler, critères d'achèvement, points de blocage fréquents.
Découvrir
Objectif : comprendre ce que veulent les utilisateurs, ce que fait la concurrence, où va le marché.
/competitor-watch analyser [URL concurrente], focus sur [prix/fonctions IA], synthèse en rapport comparatif
Pouvoir expliquer en trois phrases la plus grande douleur des utilisateurs ; savoir comment la concurrence y répond et où est notre différence.
Questions trop vagues. Remède : donner un objet précis + un angle précis + un format de sortie précis.
Définir
Objectif : transformer une idée floue en exigences claires (PRD) que tout le monde peut suivre.
/office-hours je veux faire [idée], ne donne pas encore de solution, pose-moi d'abord 5 questions clés → /prd-generator rédige un PRD complet
Indicateurs de succès clairs ; cas limites listés ; compréhensible par quelqu'un qui n'était pas là.
Le demander directement — il invente des détails. Remède : toujours lui faire d'abord "vous poser des questions" avant de rédiger.
Concevoir
Objectif : voir « à quoi ça ressemble à peu près » avant de commencer, et choisir une direction.
/design-shotgun faire 3 pistes stylistiques pour la page de connexion : A minimaliste B pro C dynamique, dans une page comparative côte à côte
Une direction choisie ; image mentale claire des pages clés.
Vouloir la perfection dès le début, s'enliser. Remède : demander d'abord 3 pistes grossières, choisir en les voyant.
Prototyper
Objectif : transformer le design en prototype réellement cliquable, interactif et testable. Principe clé : petits pas rapides.
/design-html construire le prototype → puis ajouter une fonction à la fois : "passer le graphique en bleu de marque", "ajouter bouton export CSV"… itération par dialogue
Le navigateur l'affiche vraiment ; le flux principal se parcourt sans erreur ; les données de démo sont suffisantes pour une démo.
Exprimer 20 besoins d'un coup. Remède : un seul à la fois ! Ne pas s'inquiéter de la qualité du code du prototype.
Valider
Objectif : faire tester par de vrais utilisateurs, décider par les données et non par l'intuition.
/qa tester ce prototype, cliquer sur tout ce qui est cliquable, trouver erreurs, blocages, comportements inattendus, faire une liste
Flux principal fonctionnel sans bug évident ; testé par de vrais utilisateurs ; capable de répondre par des preuves si ça vaut la peine de continuer.
Conclure après avoir cliqué soi-même deux fois. Remède : toujours le faire tester par quelqu'un d'autre, se taire et observer où il bloque.
Parcours de montée en compétence
Pas besoin d'atteindre le niveau maximum d'emblée — progressez à ce rythme.
Les limites : filet de sécurité, pas carcan
C'est précisément parce que ces 5 garde-fous existent que vous pouvez expérimenter librement et utiliser audacieusement au-delà de ces limites.
- Ne pas alimenter de vraies données sensibles — utilisez des données fictives ou anonymisées pour les prototypes.
- Ne pas écrire les clés dans le code — demandez à l'équipe des identifiants de test dédiés.
- Confirmez vous-même toute action irréversible — publication, suppression, dépenses : c'est vous qui appuyez sur le dernier bouton.
- Ne touchez pas aux systèmes en production — les prototypes tournent uniquement en local ou en environnement de test.
- En cas de doute, demandez — conformité, paiements, confidentialité, choix techniques : consultez d'abord le lead de l'équipe.
Parcours de progression sur trois semaines
| Semaine | Objectif | Actions concrètes |
|---|---|---|
| Semaine 1 | Surmonter la peur | Installer l'environnement, faire tourner la première page, pratiquer 3 dialogues par jour. |
| Semaine 2 | Un vrai essai | Prendre un vrai petit besoin et parcourir le cycle « rédiger le PRD → faire le prototype ». |
| Semaine 3 | Boucle autonome | Parcourir intégralement le cycle « idée → prototype → test avec un collègue → amélioration ». |
Annexes
A · Quatre règles de prompts
| Règle | ❌ À ne pas dire | ✅ À dire |
|---|---|---|
| Précis | Fais une belle page | Page de connexion, carte centrée, email + mot de passe, bouton bleu #3B82F6 |
| Donner le contexte | Ajouter une fonction export | Ajouter un bouton export en haut à droite du tableau de bord, télécharger le CSV des résultats filtrés actuels |
| Étape par étape | Exprimer 15 besoins à la fois | Un à la fois, voir le résultat avant de passer au suivant |
| Donner une référence | Ajuster les couleurs | Couleur principale #3B82F6, référence à la palette de Stripe |
B · Référence rapide des compétences courantes
Dans le dialogue, tapez directement / pour voir la liste complète. Les plus utilisées par les PM : /office-hours affiner une idée · /prd-generator rédiger le PRD · /competitor-watch veille concurrentielle · /design-shotgun plusieurs pistes · /design-html prototype · /qa tests · /make-pdf export PDF.
C · FAQ débutant
Q : Il a fait une erreur et je ne connais pas le code — comment corriger ?
Dites simplement « là ce n'est pas bon, je veux… ». Il se corrigera.
Q : Le prototype peut-il directement être utilisé comme produit final par les utilisateurs ?
Il peut servir pour des tests limités, mais pas pour une mise en production officielle. La mise en production requiert une refonte de qualité production par les développeurs.
Q : Combien de temps prend un prototype ?
Quelques heures pour les simples, 1 jour pour les complexes. Si rien ne sort au-delà de 1 jour, le besoin est trop large — découpez-le.
Q : J'ai peur de perdre du temps à tâtonner.
Tâtonner est précisément la valeur centrale de ce mode de travail. Plus on se trompe vite, plus on trouve rapidement la bonne direction.
