On a tous vécu cette scène : une salle (ou un call) avec huit personnes, un board couvert de post-its, et un vote à main levée pour décider quelle fonctionnalité entre dans le prochain sprint. Trois mois plus tard, la feature livrée ne résout rien de concret. Le problème ne vient pas des participants, il vient du processus de décision lui-même.
Coûts cachés de mise en oeuvre : ce que le vote classique ne capte jamais
Quand on demande à un groupe de voter pour une fonctionnalité, chaque participant projette sa propre douleur. Le support vote pour le bouton qui réduirait ses tickets. Le commercial vote pour la feature que son prospect a mentionnée hier. Le designer vote pour la refonte qui lui tient à coeur.
A découvrir également : Avantages de l'intelligence artificielle dans le e-commerce : boostez vos ventes en ligne !
Le résultat agrégé donne un classement. Ce classement a l’air démocratique, mais il masque une réalité : personne n’a estimé ce que la feature coûte réellement une fois en production.
Les pratiques récentes montrent une montée en puissance des ateliers de co-priorisation intégrant les équipes opérationnelles (support, sales, ops, compliance) plutôt que le seul noyau produit. L’objectif : capter les coûts de formation, de support post-livraison et de dette réglementaire avant de classer quoi que ce soit. Cette intégration des contraintes métier apparaît désormais dans certaines fiches de poste de chef de produit, mais reste absente de la majorité des méthodes de vote classique.
Lire également : SMS Groupés : Envoyer Rapidement et Facilement de Multiples Messages !
Quand on vote sans cette couche, on finit par livrer une fonctionnalité dont le coût de maintenance dépasse la valeur qu’elle génère. Le vote classique produit un classement déconnecté de la réalité opérationnelle.
Buy a feature : simuler la contrainte budgétaire pour forcer l’arbitrage
La méthode « Buy a feature » (ou « acquérir une fonctionnalité ») repose sur un mécanisme simple : on distribue une enveloppe fictive à chaque participant, et chaque fonctionnalité a un prix. La somme individuelle est insuffisante pour acheter les features les plus chères. Il faut donc négocier, se regrouper, renoncer.
- La somme distribuée à chaque participant doit rester inférieure au prix de la fonctionnalité la plus coûteuse, ce qui oblige la coalition
- Le prix affiché peut refléter le coût réel de développement ou un coût pondéré intégrant maintenance et support, selon ce qu’on veut tester
- Le budget global du groupe doit être inférieur au total des prix affichés, pour que le renoncement soit structurel et pas optionnel
Ce système change la dynamique. Au lieu de cocher des cases individuellement, les participants doivent expliquer pourquoi telle fonction mérite qu’on mette de l’argent dessus. Le débat remplace le clic silencieux.
On passe d’un jugement individuel (« je veux ça ») à une négociation collective (« on finance ça ensemble, et voici pourquoi »). La différence paraît subtile. En pratique, elle filtre les préférences personnelles au profit de la valeur partagée.
Pourquoi le vote par classement produit des roadmaps médiocres
Le vote classique souffre de plusieurs biais structurels que la méthode feature by feature contourne par design.
Le premier problème est la capture par le volume. Quand on agrège des votes individuels sans pondération, les fonctionnalités « évidentes » (un bouton d’export, un dark mode) raflent les voix. Ces features sont faciles à comprendre en deux secondes, donc faciles à voter. Les options plus complexes, celles qui touchent à l’architecture ou au modèle économique, restent en bas du classement faute de temps d’explication.
Le deuxième problème est l’absence de coût d’opportunité. Voter pour cinq features sur une liste de quinze ne coûte rien au votant. Il n’a pas à renoncer. Dans un atelier Buy a feature, chaque choix implique un renoncement explicite, ce qui force une évaluation plus honnête.
Le troisième problème concerne le feedback déguisé en demande. Jason Evanish, dans son analyse des systèmes de feature voting, souligne qu’on obtient des fonctionnalités plutôt que des problèmes. Un utilisateur qui vote pour « ajouter un filtre par date » exprime en réalité un problème de navigation qu’un filtre ne résoudra peut-être pas. Le vote capture la solution imaginée, pas le besoin réel.
Double arbitrage valeur et impact : la couche que personne n’ajoute
Même la méthode Buy a feature, dans sa version classique, reste centrée sur la valeur fonctionnelle. On négocie pour financer ce qui apporte le plus de valeur au client ou au business. Les retours d’expérience récents en co-priorisation montrent qu’une couche supplémentaire émerge : obliger les participants à expliciter non seulement la valeur client, mais aussi l’impact écologique ou sociétal de chaque fonctionnalité avant de la financer.
Concrètement, ça signifie qu’une feature qui génère de la valeur business mais alourdit l’empreinte (infrastructure serveur, flux de données, packaging physique) doit être défendue en tenant compte de ce coût. Ce double arbitrage n’apparaît pas dans les ateliers de priorisation standard. Les équipes qui l’intègrent rapportent des choix de roadmap différents, avec des renoncements qu’un vote classique n’aurait jamais provoqués.
Les retours varient sur ce point : certaines équipes trouvent que ça ralentit l’atelier sans changer les décisions finales. D’autres constatent que ça élimine des features « nice to have » qui auraient autrement survécu par inertie.
Priorisation produit en atelier : structurer la méthode pour que le choix tienne
Sur le terrain, la différence entre un atelier qui produit une roadmap respectée et un atelier dont les conclusions finissent dans un Google Doc oublié tient à trois éléments.
- Le prix des features doit être calibré en amont avec l’équipe technique et les ops, pas inventé par le facilitateur la veille. Si le prix ne reflète pas une réalité de mise en oeuvre, la négociation tourne à vide
- Les participants doivent inclure au moins une personne du support ou de la compliance, pas uniquement des profils produit et design. Sans cette voix, on reproduit les angles morts du vote classique
- Le résultat de l’atelier n’est pas un backlog figé mais un ensemble de paris explicites : « on finance cette feature parce qu’on pense qu’elle résout tel problème, et on le vérifiera avec tel indicateur »
Le processus de décision produit ne s’améliore pas en changeant d’outil de vote. Il s’améliore en changeant ce qu’on demande aux participants de mettre en jeu. Le vote classique ne demande rien. Le feature by feature demande un renoncement. C’est cette contrainte qui transforme une préférence en décision.
