Écrire un PRD à partir d’une demande de fonctionnalité d’une ligne
6 min de lecture
La plupart des PRD commencent de la même façon : un doc vide et une idée d’une ligne comme « laisser les utilisateurs exporter leurs données ». À partir de là, c’est facile d’écrire librement tout ce qui vient en premier à l’esprit, généralement les exigences, et de réaliser trois paragraphes plus loin qu’il n’y a nulle part dans le doc d’énoncé du problème ni de métrique de succès. Un PM enthousiaste à propos d’une idée de fonctionnalité a tendance à commencer par écrire la mécanique de son fonctionnement, les champs exacts, le placement exact du bouton, bien avant de s’arrêter pour écrire quel problème elle résout vraiment.
Attention
Un doc vide ne te rappelle pas quelles sections un PRD a besoin. Il ne fait que refléter l’ordre dans lequel tu as pensé aux choses, ce qui est rarement l’ordre dans lequel un relecteur s’attend à les lire.
Une idée de fonctionnalité est une phrase. Un PRD est une structure. Écrire librement t’obtient la phrase, développée.
Pourquoi écrire librement saute des sections sans que tu le remarques
Écrire à partir d’une page vide signifie que tu inventes la structure au fur et à mesure, et c’est facile d’écrire les parties qui semblent évidentes, généralement les exigences, en sautant les parties qui demandent plus de réflexion, comme nommer le vrai problème ou choisir une métrique qui prouve que la fonctionnalité a marché. La section des exigences est concrète et satisfaisante à écrire, puisque c’est une liste de choses précises et vérifiables. L’énoncé du problème demande de prendre du recul et d’articuler pourquoi tout ça compte, ce qui est un type de réflexion différent et plus difficile, et c’est la partie qui se fait sauter la première sous la pression du temps.
Prends une idée d’une ligne comme « laisser les utilisateurs exporter leurs données en CSV ». Un PM enthousiaste à propos de l’idée pourrait passer vingt minutes à détailler exactement quels champs devraient figurer dans l’export et ce que le bouton devrait dire, et ne réaliser qu’en envoyant le doc pour relecture qu’il n’y a nulle part de phrase expliquant pourquoi ça compte, que le support reçoit des demandes d’export manuel depuis des mois. Un relecteur qui ouvre ce doc n’a aucun moyen de juger si les exigences proposées résolvent vraiment le vrai problème, parce que le vrai problème n’a jamais été écrit.
Avant : ouvre un doc vide, commence à écrire les exigences de l’idée de fonctionnalité, réalise plus tard que l’énoncé du problème et les métriques de succès manquent.
Après : donne à Claude l’idée d’une ligne et le problème qu’elle résout, et reçois en retour un premier brouillon structuré, problème, objectifs, exigences et métriques, avec chaque section déjà en place à affiner.
Un processus pour un premier brouillon structuré
- 1
Énonce l’idée de fonctionnalité et le problème qu’elle résout
Une phrase pour chacun suffit pour démarrer. « Laisser les utilisateurs exporter leurs données en CSV, parce que le support n’arrête pas de recevoir la demande manuellement » donne à Claude à la fois le quoi et le pourquoi.
- 2
Demande une structure fixe, pas un brouillon ouvert
Demande précisément un énoncé du problème, un petit nombre d’objectifs, des exigences fonctionnelles et des métriques de succès, dans cet ordre. Une structure fixe est ce qui rend le brouillon relisable au lieu d’un essai.
- 3
Donne un vrai chiffre pour les objectifs et les métriques
Demande un nombre précis, trois objectifs, deux métriques, plutôt que « quelques objectifs ». Un chiffre force une priorisation au lieu d’une liste ouverte qui ne cesse de s’allonger.
- 4
Traite le brouillon comme une structure de départ, pas un doc final
Relis et réécris chaque section avec ta propre voix. La valeur du premier brouillon est que rien ne manque, pas que la formulation soit définitive.
Nous voulons laisser les utilisateurs exporter leurs données en CSV. Rédige un PRD d’une page avec un énoncé du problème, trois objectifs, des exigences fonctionnelles, et deux métriques de succès qu’on pourrait suivre dans les 30 premiers jours.
”Si l’idée de fonctionnalité vient d’une source précise et connue, un groupe de tickets de support, une demande client, un écart concurrentiel, cela vaut le coup de le dire explicitement à Claude, puisqu’un énoncé du problème ancré dans une vraie source nommée se lit comme bien plus crédible pour un relecteur qu’un énoncé plausible mais générique.
Cette idée vient directement de 15 tickets de support le mois dernier, tous demandant un moyen de récupérer leurs données sans contacter le support. Réécris l’énoncé du problème pour référencer cette vraie source précisément, pas une description générique du besoin.
”
Dans Claude Tutorial
Partir d’une structure fixe plutôt que d’une page vide est transférable.
Travailler à partir d’un ensemble de sections connu, au lieu d’inventer une structure en écrivant, s’applique bien au-delà des PRD. L’appli a une leçon complète sur le sujet, avec de la pratique qui se transfère à tout document dont les relecteurs attendent une forme précise.
Quand les objectifs ne correspondent pas aux métriques
Un écart courant dans un premier brouillon est un objectif sans métrique associée, ou une métrique qui ne prouve pas vraiment que l’objectif énoncé s’est produit. Ça vaut le coup de repérer ce décalage avant que le doc ne sorte, pas après que quelqu’un demande comment tu sauras que la fonctionnalité a marché. Un objectif comme « réduire la charge du support » associé à une métrique comme « nombre d’exports effectués » semble lié mais ne prouve pas vraiment l’objectif, puisque des utilisateurs pourraient exporter leurs données constamment sans qu’un seul ticket de support soit évité.
Astuce
Demande à Claude de vérifier chaque objectif contre sa métrique directement : atteindre ce chiffre prouve-t-il vraiment l’objectif, ou juste quelque chose de corrélé avec lui ? Une métrique facile à mesurer n’est pas automatiquement la bonne.
Voici les trois objectifs et les deux métriques de ce brouillon de PRD. Pour chaque objectif, dis-moi honnêtement si les métriques prouvent vraiment qu’il s’est produit, ou mesurent juste quelque chose d’adjacent.
”Si une métrique se révèle vraiment difficile à suivre avec l’outillage existant, ça vaut le coup de signaler cette contrainte tôt plutôt que de livrer un PRD avec une métrique de succès que personne ne peut vraiment mesurer une fois la fonctionnalité en production.
Une de ces métriques demanderait un suivi que nous n’avons pas actuellement en place. Propose une métrique qui prouve le même objectif mais qui soit réaliste à mesurer avec notre configuration analytique existante.
”Continuer la lecture
- Affiner un PRD avant de l’envoyer en relecture : tester le brouillon structuré que produit cet article avant qu’il n’atteigne un relecteur.
- Écrire un document de roadmap qui explique les compromis : ce qui se passe une fois que cette idée de fonctionnalité doit rivaliser avec d’autres pour une place sur la roadmap.
- Transformer des tickets de support en thèmes prioritaires : une source de vraies idées de fonctionnalités à partir desquelles écrire des PRD en premier lieu.