• L’âge d’or du grimoire : Quand le volume rassurait
• Pourquoi l’omniscience est une erreur de calcul
• Sortir du « Build Trap » : L’espace du problème avant l’espace de la solution
• De l’administrateur de backlog au stratège
• Vers un PRD au service de l’action
• Quels freins persistent ?
  • La peur de l’incertitude
  • La peur de l’inconnu
  • Autonomie versus contrôle
• Le Pitch comme synthèse
• Sources

Historiquement, le PRD – ou « Product Requirement Document » – était un document massif de 20 à 30 pages détaillant chaque aspect fonctionnel pour éviter les questions des ingénieurs. Cependant, cette bible de l’équipe technique pouvait mener droit dans le mur, surtout lorsque nous naviguons dans les eaux tumultueuses des marchés modernes.

Nous sommes ainsi passés d’une ère de la « spécification rassurante » à une ère de la « validation d’hypothèse ». Le PRD n’est plus ce grimoire sacré censé protéger le Product Manager des imprévus ; il est devenu l’instrument de navigation qui permet à une équipe d’avancer dans le brouillard de l’incertitude.

Pour comprendre cette mutation, il faut revenir à l’essence même de ce qu’est un produit : une réponse à une action humaine.

§L’âge d’or du grimoire : Quand le volume rassurait

Dans l’ancien paradigme du Product Management, la valeur d’un Product Manager était souvent indexée au poids de son dossier de spécifications. Melissa Perry nous le raconte dans Escaping the Build Trap :

« C’était mon premier mois en tant que Product Manager, et je venais de terminer mon tout premier document de spécifications produit. (…) Vingt et une pages, quatorze maquettes magnifiquement conçues et chaque cas d’erreur connu de l’homme. Les développeurs allaient être parés. Il n’y aurait pas besoin de poser une seule question. »

Cette approche reposait sur un postulat tacite : si nous réfléchissons assez fort et assez longtemps, nous pouvons éliminer l’incertitude. En tant qu’ancien développeur, je connais bien ce biais. Nous voulons du déterminisme, que A + B donne toujours C. Nous écrivons donc des pages et des pages pour éviter de nous parler, pour éviter la friction de la discussion, pensant ainsi optimiser le temps de production.

Pourtant, cette « optimisation » est une illusion. En cherchant à tout prévoir, nous créons une rigidité qui interdit l’adaptation. Nous traitons le logiciel comme un pont de béton alors qu’il est un organisme vivant : le produit évolue car les besoins changent avec le temps, et le logiciel, surtout avec le cloud, apporte cette opportunité inédite dans l’Histoire d’être modifiable après livraison.

Le PRD de trente pages cesse alors d’être un outil de construction pour devenir une barrière à la connaissance.

§Pourquoi l’omniscience est une erreur de calcul

Ludwig von Mises, dans L’Action Humaine, nous rappelle que l’homme agit pour passer d’un état de moins grande satisfaction à un état de plus grande satisfaction. Mais cette action se déroule toujours dans le temps, et donc dans l’incertitude.

Mises explique que même si nous maîtrisons tout le contexte de l’action à l’instant donné, plus nous nous projetons loin dans le futur, plus l’incertitude croît. Transposé au Product Management, cela signifie que plus notre PRD est détaillé sur des fonctionnalités qui ne seront développées que dans 3, 6 ou 9 mois, plus nous aurons de chances d’écrire de la fiction.

Le PRD exhaustif est une tentative de planification centrale à l’échelle d’une fonctionnalité. Or, la connaissance est dispersée (comme l’enseignait Hayek). Le développeur a une connaissance technique que le Product Manager n’a pas ; l’utilisateur a une réalité d’usage que nous ne pouvons que deviner.

Prétendre tout fixer à l’avance, c’est ignorer la valeur de l’information qui va émerger pendant la construction et l’utilisation du produit.

§Sortir du « Build Trap » : L’espace du problème avant l’espace de la solution

Le danger du PRD « à l’ancienne », c’est qu’il nous enferme dans ce que Melissa Perry appelle le Build Trap (le piège de la construction) : On mesure le succès au nombre de fonctionnalités livrées (la quantité) plutôt qu’à la valeur créée (la qualité de la réponse au besoin). Pour en sortir, le PRD moderne opère une distinction radicale entre l’espace du problème et l’espace de la solution.

Un produit n’a de sens que s’il résout une insatisfaction spécifique. Carl Menger, le père de l’école autrichienne, définissait un « bien » par quatre conditions :

• Un besoin humain.
• Des propriétés permettant de satisfaire ce besoin.
• La connaissance de cette relation de cause à effet.
• La disposition du bien.

Un bon PRD aujourd’hui doit se concentrer sur les trois premiers points : il doit valider que le problème est réel et qu’il se trouve bien sur le chemin du besoin de l’utilisateur (son but), avant de se perdre dans les détails d’implémentation.

Si nous ne pouvons pas définir le problème en une demi-page, aucune spécification de vingt pages ne sauvera notre fonctionnalité. La clarté et la brièveté sont les gardes-fous de la pertinence.

§De l’administrateur de backlog au stratège

Si le PRD ne sert qu’à administrer des tickets et des tâches, il est inutile. Marty Cagan, dans Inspired, souligne qu’il existe trois façons pour un Product Manager de travailler, et que deux d’entre elles mènent à la médiocrité : « Le Product Manager peut remonter chaque problème et chaque décision au PDG. Dans ce modèle, le Product Manager est en fait un administrateur de backlog. (…) Le Product Manager peut aussi convoquer une réunion avec toutes les parties prenantes et les laisser s’étriper. C’est la conception par comité. (…) Dans ce modèle, très courant dans les grandes entreprises, le Product Manager est en fait un administrateur de roadmap. »

La troisième voie est celle du Product Manager responsable de la valeur et de la viabilité. Dans ce contexte, le PRD devient un outil de communication stratégique. Son rôle n’est pas de dire « comment » faire, car les ingénieurs sont là pour ça ; il doit donner le « pourquoi » et le « quoi » avec une précision chirurgicale. Il s’agit de réduire la friction de compréhension entre les parties prenantes pour permettre une exécution fluide.

§Vers un PRD au service de l’action

Comment, concrètement, structurer un PRD aujourd’hui pour qu’il soit un moteur d’industrialisation et non un frein bureaucratique ? Il faut viser une forme d’économie de moyens.

Le Contexte (L’individu et son besoin) : Pour qui construisons-nous ? Quel est l’objectif de l’utilisateur ? On revient ici à la définition de Menger. Si nous ne comprenons pas l’action humaine que nous essayons de faciliter, nous construisons du vide.

La Définition du Problème : Le problème est-il une friction réelle ou une hypothèse de bureau ?

Les Propositions : nous ne sommes plus là pour imposer une solution, mais pour proposer des pistes à explorer d’une part avec les développeurs, et d’autre part à valider avec les utilisateurs, car nous ne sommes jamais sûrs tant que la solution n’est pas entre leurs mains.

Les Indicateurs de Succès : Comment saurons-nous que l’insatisfaction initiale a été réduite ? Les indicateurs doivent permettre de mesurer la satisfaction des utilisateurs : est-ce qu’ils arrivent au bout du parcours, est-ce qu’ils reviennent, etc.

Cette structure favorise une compréhension partagée par l’échange : avec les développeurs sur les aspects techniques, avec les utilisateurs sur des maquettes. Les discussions deviennent productives bien plus que des dizaines de pages de spécifications.

§Quels freins persistent ?

D’après mon expérience, il persiste encore beaucoup de résistance et de scepticisme. J’ai eu l’occasion d’en voir quelques exemples.

§La peur de l’incertitude

Le frein le plus subtil auquel je me suis retrouvé confronté touche à la maîtrise de l’incertitude. En apparence, nous sommes alignés sur la logique du PRD. Mais au moment de livrer une documentation avec analyse du besoin et proposition, la réflexion tombe : et l’analyse d’impact ? Et la matrice des risques avec leurs solutions ? Très vite, nous nous retrouvons à explorer des propositions à peine ébauchées, et nous finissons avec l’équivalent de 20 ou 30 pages d’analyse en annexe de notre PRD…

Le véritable défi ici concerne la mentalité. Un article dédié serait nécessaire, mais nous sommes historiquement câblés pour concevoir des systèmes robustes, alors qu’aujourd’hui, nous devons penser nos systèmes pour se renforcer au fil des expérimentations, ce que Nassim Nicholas Taleb appelle l’antifragilité.

Pour l’heure, une solution que j’ai vu fonctionner consistait à tourner l’analyse d’impact en une analyse de l’impact… sur l’utilisateur. C’était alors l’occasion de montrer les bénéfices que nous apportons à traiter ce besoin. En parallèle, nous pouvons mener des expérimentations – ou « spikes » – avec les développeurs, et échanger avec les utilisateurs sur des maquettes.

Le PRD devient un document vivant : il s’étoffe au fur et à mesure que nous levons les incertitudes, tant sur le besoin que sur les moyens techniques que nous mettrons en œuvre sur la solution.

§La peur de l’inconnu

À mon niveau de Product Manager, je me suis également retrouvé face à des managers et « C-level » (directeurs) exigeant une roadmap à un an. Je ne suis pas expert de cette strate de responsabilité, mais il s’agit là d’être capable de boucler et/ou de justifier un budget sur l’année, donc avec des sujets concrets à traiter.

Dans mon cas, j’ai pu bénéficier du concours d’un directeur produit (« Chief Product Officer » pour l’anglicisme) qui a proposé de remonter non pas des feuilles de routes de fonctionnalités, mais d’opportunités à traiter (« opportunité » est en quelques sortes l’autre nom pour parler du besoin, mais partagé par plusieurs utilisateurs). Cette feuille de route n’était pas non plus construite sur des engagements fermes, mais sur des zones de certitude (trois prochains mois), de confiance (trimestre suivant) et d’incertitude (semestre suivant). Nous étions ainsi capables de montrer que nous maîtrisons notre produit, tout en conservant la flexibilité nécessaire pour nous adapter aux fluctuations des priorités sur le marché.

§Autonomie versus contrôle

Les développeurs sont les plus simple à convaincre, car eux-mêmes sont conscients de l’incertitude sur la solution tant que nous n’avons pas mené d’expérimentation (les fameux spikes), ou même tenté d’implémenter de solution (surtout avec les juniors).

Certains développeurs senior peuvent être paradoxalement plus complexes à convaincre : une forte expertise technique peut parfois pousser à converger rapidement vers une solution jugée évidente. D’autre part, en tant qu’ancien développeur, j’ai pu m’exposer au changement de mentalité qu’entraîne le passage en mode produit : en tant que développeur, nous sommes tournés vers la solution et la résolution du problème, beaucoup moins sur l’exploration des besoins, ce qui nous amène facilement à préférer une solution bien cadrée.

Pourtant, un levier important pour les développeurs joue sur l’autonomie : lorsque nous apportons un besoin bien défini et que nous n’imposons a priori rien concernant la solution, les développeurs ont toute latitude pour expérimenter et construire au final la solution la mieux adaptée au besoin.

Et pour aller encore plus loin, donner l’occasion aux développeurs de rencontrer des utilisateurs est la cerise sur le gâteau : le développeur a alors l’occasion de comprendre pourquoi il développe,… et peut-être finir par faire comme moi et changer de carrière ?

§Le Pitch comme synthèse

Une fois que le PRD a été travaillé, validé avec les parties prenantes et les ingénieurs, il doit aboutir à un « Pitch ». Ce n’est pas simplement un résumé, c’est la quintessence de notre compréhension du sujet. Il doit également permettre de défendre l’idée sur la roadmap, il est la preuve que nous avons éliminé le superflu pour ne garder que la valeur.

Le pitch est la conclusion logique de notre démarche :

• Il part de l’utilisateur : son but, son besoin, son contexte d’action.
• Il considère la solution comme une proposition : nous agissons avec la connaissance que nous avons, tout en restant prêts à pivoter si les résultats divergent.
• Il fournit une synthèse directe : pas de jargon inutile, pas de détails techniques, juste la ligne droite vers la résolution du problème.

C’est là que réside la véritable émancipation du Product Manager. En abandonnant l’illusion du contrôle par le document exhaustif, nous gagnons en agilité et en pertinence.

§Sources

• Escaping the Build Trap, Melissa Perry (2018).
• Inspired: How to Create Tech Products Customers Love, Marty Cagan (2018).
• L’Action Humaine, Ludwig von Mises (1949).
• Principes d’Économie Politique, Carl Menger (1871).
• How to make PRDs useful for internal stakeholders, Inside Product (2024).