« Construisons ce que les utilisateurs veulent » ne pose problème qu'au moment de dire qui sont les utilisateurs et ce que veut dire vouloir. La demande la plus votée est rarement la réponse aux deux questions.
La réponse courte. La procédure tient en sept étapes : collecter, dédupliquer, catégoriser, segmenter, évaluer, décider, communiquer. Les étapes qui font le plus de différence sont la deuxième et la dernière, et ce sont celles qu'on saute le plus souvent.
Les sept étapes
1. Collecter dans un seul endroit. Rien de ce qui suit n'est fiable sur une base partielle. C'est l'objet de la centralisation.
2. Dédupliquer. Sept cents messages ne sont pas sept cents besoins. Sans cette étape, le volume donne une fausse impression de richesse et ralentit tout le reste.
3. Catégoriser. Une taxonomie courte, cinq à huit entrées. Vingt catégories garantissent que deux personnes classeront le même retour différemment.
4. Segmenter. Regarder de quels comptes viennent les demandes de chaque groupe. Une même demande change de nature selon qu'elle vient de l'offre d'entrée ou de comptes en renouvellement.
5. Évaluer. Fréquence par compte, impact réel, pertinence produit, cohérence stratégique, effort estimé. Les critères sont détaillés dans la définition.
6. Décider. Choisir, et écrire pourquoi. La trace vaut autant que la décision : elle évite de rediscuter le même sujet au trimestre suivant.
7. Communiquer. À ceux qui ont demandé, y compris quand la réponse est non.
Pourquoi la demande la plus votée n'est pas la réponse
Trois raisons se cumulent, et elles n'ont rien à voir avec la qualité des utilisateurs.
Ceux qui votent ne sont pas ceux qui paient, ni ceux qui partent. Les comptes les plus engagés commercialement passent souvent par leur interlocuteur habituel plutôt que par un tableau public.
Une demande formulée est déjà une solution. L'utilisateur propose ce qu'il imagine faisable. « Il faudrait un export Excel » peut vouloir dire « je ne fais pas confiance à vos chiffres ». Construire l'export laisse le problème entier.
Le silence ne vote pas. Ceux qui ont abandonné une tâche sans rien dire ne figurent nulle part. Ils sont pourtant le groupe dont le comportement coûte le plus cher.
La correction ne consiste pas à ignorer les votes, mais à les lire comme un signal de fréquence parmi cinq critères.
L'étape de déduplication mérite du soin
C'est l'étape la plus ingrate et celle qui change le plus le classement final.
Deux formulations peuvent décrire le même besoin, et deux formulations identiques peuvent décrire des besoins différents. « Pouvoir exporter » ne veut pas dire la même chose pour quelqu'un qui prépare un rapport mensuel et pour quelqu'un qui migre vers un autre outil.
Le test utile : deux demandes sont un doublon si la même livraison satisfait les deux personnes. Sinon ce sont deux besoins qui se ressemblent.
Un tableau de votes déplace une partie de ce travail vers l'utilisateur, qui voit les demandes existantes et se joint à celle qui correspond. C'est un des intérêts réels du format, au-delà du comptage.
Décider quand les critères se contredisent
Le cas normal n'est pas celui où un besoin gagne sur les cinq critères, c'est celui où il gagne sur deux et perd sur trois.
Quelques règles de départage qui tiennent à l'usage :
- Un blocage l'emporte sur une fréquence élevée. Trois comptes empêchés de travailler pèsent plus que cinquante mentions de confort.
- La cohérence stratégique est un veto, pas un point. Un besoin hors direction ne remonte pas parce qu'il est fréquent.
- À égalité, choisir ce qui se mesure. Un besoin dont on saura dire s'il a été résolu vaut mieux qu'un besoin flou, à valeur estimée identique.
- Ne pas arbitrer sur l'effort seul. Faire d'abord ce qui est facile produit un produit fait de petites choses.
Ne pas s'arrêter à la décision
Une file priorisée ne sert à rien si personne ne sait ce qui a été décidé.
Deux mécanismes suffisent et coûtent presque rien une fois en place. Un changement d'état sur la demande prévient ceux qui l'avaient soutenue. Une feuille de route publique montre ce qui est en cours sans engager de date.
Reste la mesure. Une fonctionnalité livrée à la suite d'une demande devrait être utilisée par ceux qui l'avaient demandée. Quand ce n'est pas le cas, c'est en général que l'étape 2 a fusionné deux besoins distincts, ou que l'étape 5 a retenu la solution proposée plutôt que le problème.
Questions fréquentes
Combien de temps consacrer à cette procédure ?
Une à deux heures par cycle de planification pour une équipe de taille modeste, à condition que le tri de premier niveau soit fait au fil de l'eau. Si la file arrive brute, la séance sert à trier et pas à décider.
Faut-il un score chiffré ?
Utile au-delà d'une trentaine de besoins actifs, pour éviter que la discussion reparte de zéro à chaque séance. En deçà, le classement est en général évident et le score ajoute une fausse précision.
En quoi cela diffère-t-il du framework du fondateur ?
Cette procédure ordonne une file existante. Le framework du fondateur couvre la chaîne complète, de la capture jusqu'à la mesure après livraison, en incluant la validation auprès des utilisateurs.
Que faire des demandes qui reviennent après un refus ?
Les rouvrir si le contexte a changé, sinon renvoyer la décision écrite. La répétition est elle-même un signal quand elle vient de comptes nouveaux.
Pour aller plus loin
- La priorisation du feedback : définition et exemples
- Du feedback aux fonctionnalités : le framework SaaS
- Segmenter le feedback pour mieux prioriser sa roadmap
Une file priorisée se tient mieux là où les utilisateurs voient les états. Voyez les demandes de fonctionnalités et les tarifs.