Idée principale

Le Product Manager répond du choix produit : pourquoi ce sujet, pour quelle cible, avec quel impact attendu, dans quel ordre. Les développeurs répondent de la qualité technique de ce qu'ils livrent : le code, la base de code, ce qui part en production. Si l'arbitrage produit est mauvais, le premier l'assume ; si le code est fragile, peu testé, mal compris ou difficile à maintenir, les seconds l'assument.

Ces deux zones se parlent en permanence — un bon produit se construit dans l'échange entre choix, faisabilité, usage et contraintes techniques —, et c'est là que la confusion s'installe. Parce que la décision a été discutée, chacun peut se considérer comme partiellement engagé par celle de l'autre, donc entièrement responsable d'aucune.

Le dialogue sert à instruire la décision, pas à la mutualiser. Traiter les développeurs comme des exécutants et diluer leur responsabilité dans une décision collective sont deux manières opposées de leur retirer la même chose : la propriété de ce qu'ils livrent.

Pourquoi c'est important

Cela donne un test praticable sur un différend : demander non pas qui a participé à la décision, mais qui aurait pu la bloquer seul. La zone se lit à ce droit de veto, pas à la présence en réunion.

Cela évite aussi la lecture inverse, tout aussi coûteuse : des zones étanches où le produit ne discute jamais la faisabilité et la technique jamais l'usage.

Nuances et limites

La frontière n'est pas toujours nette. Un choix de conception technique peut déterminer un comportement visible par l'utilisateur, et un arbitrage produit peut imposer une dette. Ce qui compte alors est de savoir laquelle des deux zones tranche, pas de faire disparaître le sujet.

Et le partage suppose que les développeurs disposent réellement de la marge d'arbitrer leur propre qualité — sans cette marge, la responsabilité leur est attribuée sans leur avoir été donnée.

Questions ouvertes

• Qui tranche quand un arbitrage produit ne peut être tenu qu'au prix d'une dette technique que l'équipe refuse ?