Le réflexe
Le rôle est traité comme de la traduction. Les demandes arrivent du commercial, du fondateur, du plus gros client, et ressortent en tickets.
Du secrétariat technique avec un titre flatteur.
Le réflexe builder
Le product décide ce qu’on ne va pas faire.
Pourquoi
Une fonction qui accepte tout et le classe n’ajoute rien que la file d’attente ne faisait déjà. Sa valeur tient entièrement dans le refus. Et un refus ne tient que s’il repose sur une connaissance du client assez solide pour contredire le fondateur, et juste assez souvent pour qu’on continue à l’écouter.
Là où n’importe qui peut ajouter et personne ne peut refuser, il n’y a pas de produit. Il y a une file, et une règle implicite. Celui qui insiste le plus fort, ou qui a le titre le plus haut, passe devant. Cette règle tourne, écrite ou non.
Rien de tout ça n’est une fiche de poste. Un ingénieur qui dit “je sais le construire, je pense qu’on ne devrait pas, et voilà pourquoi” fait du product. L’agent support qui relie quinze tickets identiques à une seule étape cassée aussi. Et dans une équipe de six, celui qui doit refuser sa propre idée devant les autres, c’est en général le fondateur.
À essayer
Tiens la liste des non. Un fichier court. La demande, qui la portait, la raison du refus, la date. Range-le à côté de la roadmap, même endroit, mêmes lecteurs.
L’arbitrage devient visible, et un refus devient quelque chose qu’on rouvre dans trois mois au lieu d’une décision que personne ne peut montrer du doigt.
À discuter
C’est quoi la dernière demande significative qu’on a refusée, qui la portait, et est-ce que cette personne sait pourquoi ?