Comment construire une roadmap produit à partir du feedback

Construire une roadmap produit se résume à ceci : rassemblez ce que les clients ont déjà demandé, regroupez-le par problème derrière chaque demande, classez les groupes avec une règle que vous pouvez expliquer, décidez de votre certitude pour chacun, et publiez le résultat dans un format adapté à ceux qui le lisent. L’ordre compte. Les équipes qui commencent par une mise en page et la remplissent d’idées obtiennent un document qui a l’air fini et ne contient aucune preuve. Celles qui commencent par les demandes obtiennent une roadmap plus courte, avec une raison derrière chaque ligne.

Par où commencer pour construire une roadmap produit ?

Commencez par les preuves que vous avez déjà, pas par une page blanche. Les demandes de fonctionnalités ouvertes, les conversations de support étiquetées avec la même plainte, les notes d’appels commerciaux et les données d’usage de votre propre produit sont autant de sources. Mettez-les dans une seule liste et notez d’où vient chaque élément.

Les demandes arrivent rarement sous une forme exploitable. “Ajouter une intégration Slack” et “prévenir mon équipe quand une tâche change” peuvent être le même besoin. C’est pourquoi l’étape suivante est le regroupement, et pourquoi un outil de suivi qui fusionne les doublons vaut le coup ; demandes de fonctionnalités dupliquées explique comment faire. Gardez aussi en tête que les tickets de support et les demandes de fonctionnalités portent des signaux de nature différente, et qu’une roadmap bâtie sur un seul des deux penchera du mauvais côté.

Comment transformer des demandes en éléments de roadmap produit ?

Regroupez les demandes par problème, nommez chaque groupe comme un résultat et gardez le total. Un groupe de quatorze demandes qui décrivent toutes la perte d’un filtre au rechargement devient un seul élément : “Garder le filtre utilisé la dernière fois”. Le total va dans la colonne source, pour que quiconque lit la roadmap voie le poids derrière l’élément.

Écrivez le résultat avec les mots du client. “Implémenter la persistance des vues sauvegardées” dit à un ingénieur quoi construire et ne dit rien à un client. Formuler un résultat oblige aussi à se poser une question utile : si vous ne savez pas dire ce qui change pour le client, c’est peut-être une tâche interne qui appartient à une autre liste.

Comment décider ce qui passe en premier ?

Choisissez une règle de scoring, écrivez-la et appliquez-la à chaque élément. RICE, qui note la portée, l’impact, la confiance et l’effort, est la plus courante ; l’article d’Intercom sur RICE en est la source d’origine. Une règle plus simple marche aussi bien si vous pouvez l’expliquer : le nombre de demandes, pondéré selon que le demandeur est un compte payant actif, divisé par un effort approximatif.

Ce qui compte, c’est que la règle soit énoncée, parce que le premier client qui demande pourquoi sa demande n’est pas dans la liste voudra une réponse. Quand la règle et votre jugement divergent, dites-le dans la ligne. Prioriser les demandes de fonctionnalités passe en revue les méthodes de scoring, la question de la pondération par le revenu et ce que les votes disent ou non.

Quelle est votre certitude pour chaque élément ?

Étiquetez chaque élément avec sa confiance avant de publier quoi que ce soit. Une échelle simple à trois valeurs suffit : engagé veut dire que l’équipe serait surprise de ne pas le livrer dans la fenêtre, prévision veut dire que c’est le plan sauf changement, et exploration veut dire qu’il n’y a aucune promesse.

Cette seule colonne évite l’essentiel des dégâts d’une roadmap. Sans elle, un client lit un élément en exploration comme un engagement, les commerciaux le citent, et un trimestre plus tard c’est une réclamation. L’essai de Marty Cagan sur l’alternative aux roadmaps développe l’argument de fond : une liste de fonctionnalités avec des dates est une liste de paris présentés comme des plans, et la solution est d’être explicite sur ce que vous savez.

Quel format donner à la roadmap ?

Choisissez la disposition en dernier, selon le lecteur. Les clients qui se demandent si vous les avez entendus ont besoin d’une courte vue publique. La direction, qui demande pourquoi ce travail, a besoin de thèmes ou de résultats. Une équipe qui change de direction chaque mois s’en sort bien avec Now, Next et Later, sans dates. Exemples de roadmap produit présente six formats avec des éléments réalistes et la façon dont chacun échoue, et le template de roadmap produit donne les champs à copier une fois votre choix fait.

La plupart des équipes finissent avec deux documents : une roadmap stratégique pour les lecteurs internes et une version publique réduite qui ne montre que ce sur quoi vous acceptez d’être jugé. Si vous en publiez une, roadmap publique décrit comment la piloter avec les labels des issues que vous suivez déjà.

Comment éviter que la roadmap ne vieillisse ?

Donnez une date de revue à chaque ligne et gardez la roadmap là où le travail se trouve déjà. Une roadmap mise à jour à la main dans un outil séparé vieillit parce que le travail quotidien de personne ne l’inclut. Si chaque colonne correspond à un label sur l’issue, la roadmap change quand le label change.

Fermez la boucle quand un élément est livré. Les personnes qui l’avaient demandé doivent le savoir, et l’entrée de changelog est l’endroit habituel ; la boucle de feedback client décrit tout le chemin. Si vous décidez de ne pas construire quelque chose, dites-le aussi. Un non clair est utile à celui qui a demandé, et refuser une demande de fonctionnalité explique comment le formuler.

FAQ

Quelles sont les étapes pour construire une roadmap produit ? Rassemblez les demandes et les données, regroupez-les par problème derrière chacune, classez-les avec une règle écrite, étiquetez chaque élément selon votre certitude, choisissez un format pour le lecteur et fixez une date de revue. Partir des preuves garde la roadmap courte et défendable.

Sur quoi une roadmap produit doit-elle reposer ? Sur les demandes des clients, les thèmes du support, les données d’usage et votre stratégie, dans cet ordre, qui est aussi celui de la fréquence à laquelle on les saute. Une roadmap sans source derrière ses lignes est une liste de souhaits.

Sur quelle durée une roadmap produit doit-elle porter ? Assez longtemps pour être utile et assez peu pour rester crédible. Pour beaucoup de petites équipes, c’est le trimestre en cours en détail et un ou deux suivants en thèmes. Tout ce qui est plus loin va sous “Later”, sans dates.

Qui doit participer à la construction d’une roadmap produit ? Le product owner décide, l’ingénierie vérifie la faisabilité et l’effort, et le support et les ventes apportent les demandes et les thèmes qu’ils entendent. Les clients voient le résultat dans une version publique, mais ne la modifient pas.

Les affirmations techniques de cet article n'ont pas été vérifiées de façon indépendante. Si quelque chose est faux, dis-le-nous et nous le corrigerons.

À voir sur changeloop : Documentation développeurs, Exemples de changelog