Product Decision Record : tracer les choix produit qui structurent l'entreprise

Certaines décisions produit reviennent partout.

Elles reviennent en comité roadmap. Elles reviennent avec les sales. Elles reviennent au support. Elles reviennent dans les specs. Elles reviennent dans les tickets. Elles reviennent à chaque nouveau gros client, à chaque nouvelle opportunité, à chaque cas limite un peu visible.

Faut-il privilégier le client ou le fournisseur sur une marketplace ?

Faut-il traduire le produit dans toutes les langues demandées par les prospects ?

Faut-il accepter une exception pour un segment qui pourrait rapporter beaucoup ?

Faut-il ouvrir un périmètre si le produit ne pourra pas encore l'assumer correctement ?

Ces questions ne sont pas des features. Ce ne sont pas des tickets. Ce ne sont pas des détails d'exécution. Ce sont des décisions structurantes.

Et lorsqu'elles ne sont pas documentées clairement, l'entreprise les redécide sans arrêt.

Parfois avec les mêmes personnes. Parfois avec d'autres. Parfois avec moins de contexte. Parfois sous pression commerciale. Parfois dans l'urgence. Parfois avec une mémoire partielle de ce qui avait déjà été arbitré.

Le problème n'est pas seulement la perte de temps. Le problème est la perte de cohérence.

Une décision produit importante ne doit pas dépendre de la mémoire orale de ceux qui étaient dans la réunion.

C'est précisément le rôle d'un Product Decision Record.

L'inspiration : les ADR côté technique

Les équipes techniques connaissent déjà une pratique proche : les ADR, pour Architecture Decision Records.

Un ADR est un document court qui trace une décision d'architecture. Il explique le contexte, les options envisagées, la décision retenue et ses conséquences.

L'intérêt est simple : plusieurs mois ou plusieurs années plus tard, une personne peut comprendre pourquoi un choix technique a été fait.

Prenons un exemple.

Une application subit une montée en charge. Les clients sont plus nombreux. Les consultations augmentent. Les ralentissements deviennent fréquents. L'équipe décide alors de mettre en place une technologie de file d'attente pour traiter certains messages en asynchrone.

Ce choix n'est pas une feature.

Pendant un mois, les développeurs vont peut-être travailler sur un chantier purement technique. Ils devront se former. Ils devront modifier une partie de l'architecture. Ils ne livreront pas immédiatement une valeur métier visible pour l'utilisateur final.

Mais cette décision peut supprimer un goulot d'étranglement majeur. Elle peut permettre d'absorber dix, vingt ou trente fois la charge actuelle en ajoutant des serveurs. Elle peut aussi libérer le commerce, qui pourra vendre de nouveaux accès clients sans craindre que l'application gèle.

Un ADR permet de documenter cette décision.

Pourquoi l'a-t-on prise ? Quelles options a-t-on écartées ? Quelles conséquences accepte-t-on ? Qu'est-ce que cela permet ? Qu'est-ce que cela contraint ?

Le Product Decision Record reprend cette logique, mais côté produit.

Un PDR n'est pas une décision de feature

Un Product Decision Record documente une décision produit structurante.

Pas une opportunité.

Pas une carte Jira.

Pas une spec.

Pas une feature.

Un PDR trace une règle de décision que l'entreprise assume et qui va guider plusieurs produits, équipes ou situations futures.

Il ne dit pas : "voici la fonctionnalité à construire".

Il dit plutôt : "dans ce type de situation, voici la règle que nous appliquons".

C'est une différence importante.

Si l'on utilise les PDR pour documenter chaque arbitrage local, l'outil devient de l'administratif. Il perd sa force. Un bon PDR doit porter sur une décision assez structurante pour éviter des dizaines de rediscussions.

Sa valeur vient de sa rareté.

Une entreprise ne devrait pas produire cinquante PDR par trimestre. Quelques-uns par an suffisent. Cinq, dix, quinze, vingt maximum selon la taille et la complexité de l'organisation.

Un PDR doit être assez important pour être gardé en tête, ou retrouvé rapidement quand une question revient.

Exemple : marketplace, client ou fournisseur ?

Sur une marketplace, il existe une tension structurelle.

Quand un conflit apparaît, faut-il privilégier le client ou le fournisseur ?

On peut essayer de faire les deux. On peut chercher un compromis à chaque fois. On peut traiter chaque cas comme une exception. Mais dans beaucoup de situations, il faut bien choisir.

Si l'entreprise ne documente pas cette décision, chaque équipe risque de l'interpréter à sa manière.

Le support pourra vouloir préserver la relation client.

L'équipe partenariats pourra vouloir protéger les fournisseurs.

Le produit pourra vouloir éviter de complexifier les règles.

Les sales pourront pousser l'option qui aide le compte le plus stratégique du moment.

Et à chaque conflit, la même question reviendra.

Un PDR permet de poser une ligne directrice :

En cas de conflit, nous privilégions le client.

Cette décision ne décrit pas une feature. Elle ne décrit même pas un workflow précis. Mais elle va influencer des dizaines de décisions : règles de remboursement, politiques de litige, messages support, priorités produit, arbitrages opérationnels, communication client.

C'est exactement le bon niveau pour un PDR.

Il documente une décision transverse.

Il rend le choix explicite.

Il permet aux équipes d'avancer sans réouvrir le débat à chaque cas limite.

Exemple : les langues dans un SaaS

Prenons un autre cas, très fréquent dans les entreprises SaaS.

Les équipes commerciales veulent vendre dans plusieurs pays. Un prospect allemand demande une interface en allemand. Un prospect espagnol demande l'espagnol. Un grand compte italien demande l'italien. Chaque opportunité semble intéressante.

Mais côté produit, traduire une application ne consiste pas seulement à remplacer du texte.

Il faut traduire l'interface. Maintenir les traductions. Tester les écrans. Adapter la documentation. Former le support. Gérer les emails. Vérifier les messages automatiques. Suivre les évolutions. Éviter que certaines langues deviennent des versions dégradées du produit.

Sans décision claire, chaque nouveau prospect peut rouvrir le sujet.

Un PDR peut fixer la règle.

# PDR 004 — Langues supportées par défaut

## Statut
Validé

## Décision
Le produit est supporté par défaut en français et en anglais. Toute autre langue nécessite un seuil minimal de chiffre d'affaires annuel signé.

## Contexte
Les équipes commerciales rencontrent des opportunités dans plusieurs pays. Chaque langue ajoute un coût de traduction, de maintenance, de support, de documentation et de qualité produit.

## Alternatives considérées
- Traduire toutes les langues demandées : trop coûteux et difficile à maintenir.
- Ne supporter que le français : trop limitant pour le développement commercial.
- Supporter français et anglais par défaut, puis ouvrir les autres langues sous condition.

## Décision retenue
Français et anglais sont supportés par défaut. Les autres langues sont ouvertes seulement si des contrats signés dépassent un seuil défini.

## Conséquences
- Meilleure maîtrise de la qualité.
- Moins de promesses commerciales difficiles à tenir.
- Certaines opportunités commerciales seront refusées ou différées.

## Conditions de réévaluation
La décision sera réévaluée si l'IA réduit fortement le coût de traduction tout en maintenant un niveau de qualité acceptable, ou si un nouveau segment stratégique impose une langue.

Ce PDR ne ferme pas définitivement le sujet.

Il donne une règle actuelle.

Il permet aux sales de savoir ce qu'ils peuvent vendre. Il permet au produit de refuser des demandes sans refaire toute l'argumentation. Il permet à la direction de comprendre le coût réel d'une ouverture linguistique.

Et il contient une condition de réévaluation.

Si l'IA rend possible des traductions fiables à faible coût, la décision peut changer. Si un nouveau segment stratégique impose une langue, la décision peut changer. Si plusieurs contrats signés justifient l'investissement, la décision peut changer.

Mais si elle change, on ne réécrit pas l'ancien PDR.

On en crée un nouveau.

Ce qui mérite un PDR

Toutes les décisions produit ne méritent pas un PDR.

C'est même le point le plus important.

Un PDR doit rester rare. Sinon, il devient une forme de documentation supplémentaire que personne ne lit.

Une décision mérite probablement un PDR si elle est transverse, structurante, durable, coûteuse à inverser, susceptible d'être rediscutée, utile à plusieurs équipes, et assez importante pour influencer plusieurs décisions futures.

À l'inverse, une décision ne mérite probablement pas de PDR si elle est locale, ponctuelle, liée à une seule feature, déjà couverte par une règle existante, sans conséquence durable, ou trop évidente pour être rediscutée.

Le test est simple :

Si la décision ne va éviter aucune rediscussion future, elle n'a probablement pas besoin d'un PDR.

Un PDR n'est pas là pour documenter tout ce que le Product Manager décide.

Il est là pour documenter les choix qui structurent le cadre dans lequel les Product Managers, les sales, le support, les opérations et parfois la direction vont ensuite prendre des décisions locales.

Un format court, structuré, suffisant

Un PDR doit rester court.

Le format sert à éviter les oublis, pas à produire un dossier administratif.

Un template utile peut ressembler à ceci :

# PDR <numéro> — <titre>

## Statut
Proposé | Validé | Remplacé par PDR <numéro> | Abandonné

## Date
YYYY-MM-DD

## Décision
Une phrase claire.

## Contexte
Pourquoi cette décision est nécessaire maintenant.

## Alternatives considérées
- Option A : ...
- Option B : ...
- Option C : ...

## Décision retenue
Ce que l'entreprise choisit.

## Raisons du choix
- ...
- ...

## Conséquences
### Positives
- ...

### Négatives
- ...

### Risques
- ...

## Conditions de réévaluation
Ce qui pourrait justifier un nouveau PDR.

## Décideurs et personnes consultées
- Décideur :
- Consultés :

## Références
- ...

Le contenu exact peut varier.

Mais l'essentiel doit toujours être présent : le contexte, la décision, les alternatives, les raisons du choix, les conséquences, les décideurs, et ce qui pourrait faire évoluer la décision.

Le PDR ne doit pas devenir un PRD.

Il ne doit pas décrire toute l'exécution.

Il doit documenter le pourquoi.

On ne réécrit pas l'histoire

Un PDR validé ne s'efface pas.

Il ne se réécrit pas pour cacher un changement de position.

S'il faut changer la décision, on crée un nouveau PDR qui remplace l'ancien.

C'est essentiel.

Le PDR n'est pas là pour prouver que l'entreprise avait toujours raison. Il est là pour comprendre pourquoi elle a décidé ce qu'elle a décidé à un moment donné.

Dans l'exemple des langues, le premier PDR peut dire : français et anglais uniquement par défaut, autres langues sous condition de chiffre d'affaires signé.

Deux ans plus tard, l'IA peut changer le coût de traduction. La qualité peut devenir suffisante. Le support peut s'outiller. Le produit peut décider que les langues secondaires seront désormais traduites automatiquement, avec revue humaine sur les parcours critiques.

Ce n'est pas une contradiction.

C'est une nouvelle décision dans un nouveau contexte.

L'ancien PDR reste utile, parce qu'il explique pourquoi l'entreprise avait initialement refusé de traduire partout. Le nouveau PDR explique pourquoi ce refus n'est plus adapté.

Cette traçabilité évite l'amnésie produit.

Elle évite aussi les procès internes absurdes : "Pourquoi on n'a pas fait ça avant ?" Peut-être parce qu'avant, le coût, la qualité, les ressources et le contexte commercial ne permettaient pas de le faire correctement.

PDR, PRD, roadmap, backlog : ne pas mélanger

Un PDR n'est pas un PRD.

Un PRD décrit ce que l'on veut construire.

Un PDR explique pourquoi l'entreprise a choisi une règle de décision.

Une roadmap montre ce que l'entreprise fait, prépare, envisage ou refuse dans un horizon donné.

Un backlog organise le travail exécutable, ou bientôt exécutable.

Un ticket découpe une action opérationnelle.

Le PDR est en amont.

Il peut influencer une roadmap. Il peut contraindre un PRD. Il peut expliquer pourquoi certains tickets existent ou n'existent pas. Mais il ne les remplace pas.

C'est justement parce qu'il reste à ce niveau qu'il est utile.

Si un PDR descend trop bas, il devient une spec déguisée.

Si une roadmap essaie de jouer le rôle d'un PDR, elle mélange communication et règle de décision.

Si un ticket porte une décision structurante, il la rend invisible pour le reste de l'entreprise.

Chaque outil doit rester à son niveau.

Le PDR n'est pas de l'administratif

On peut facilement mal utiliser les PDR.

On peut en créer trop. Les rendre trop longs. Les transformer en comptes rendus. Les utiliser pour se couvrir. Les faire valider par trop de monde. Les écrire après coup pour justifier une décision déjà imposée.

Dans ce cas, oui, le PDR devient de l'administratif.

Mais ce n'est pas son usage normal.

Un bon PDR enlève de l'administratif.

Il évite de refaire cinquante fois la même explication.

Il évite de rouvrir le même arbitrage à chaque gros prospect.

Il évite de dépendre de la mémoire d'une personne.

Il évite aux équipes de naviguer entre des règles implicites, des exceptions non dites et des décisions contradictoires.

La documentation n'est pas le problème.

La mauvaise documentation est le problème.

Un PDR court, rare, clair et immuable n'alourdit pas l'organisation. Il lui donne une colonne vertébrale décisionnelle.

Conclusion

Une entreprise produit ne manque pas seulement de priorités.

Elle manque souvent de mémoire sur ses décisions.

Elle sait ce qu'elle a fait, mais elle ne sait plus toujours pourquoi elle l'a fait. Elle se souvient d'une conclusion, mais pas du contexte. Elle applique une règle localement, puis l'oublie ailleurs. Elle rouvre une discussion parce que personne ne retrouve l'arbitrage initial.

Le Product Decision Record sert à éviter cela.

Il transforme une décision implicite en règle explicite.

Il documente les choix produit qui structurent l'entreprise.

Il permet de dire : "Nous avons déjà tranché ce sujet. Voici pourquoi. Voici les conséquences que nous acceptons. Voici les conditions qui pourraient nous faire changer."

Un bon PDR n'ajoute pas une couche de documentation.

Il enlève des dizaines de discussions inutiles.