Comment utiliser une roadmap publique pour renforcer la rétention

Un client qui a demandé quelque chose il y a quatre mois se pose une question simple : est-ce que quelqu'un a lu son message. Une roadmap publique répond à cette question sans qu'il ait à la poser.

La réponse courte. Une roadmap publique est la vue côté client de ce que vous avez décidé de faire. Elle peut soutenir la rétention en rendant visible que le feedback est traité, mais elle ne la garantit pas : un client dont le problème n'est pas résolu ne reste pas parce qu'il voit une liste bien tenue.

Ce qu'elle change réellement

Trois effets sont observables, et il vaut mieux s'en tenir à ceux-là.

Le silence cesse d'être ambigu. Sans page publique, un client qui n'a pas de nouvelles conclut que rien ne se passe. C'est faux la plupart du temps, et impossible à démentir sans écrire à chacun.

Les questions répétitives diminuent. « Est-ce que vous prévoyez X » se pose une fois sur une page consultable plutôt que dix fois au support.

Les demandes deviennent situables. Un client peut voir que sa demande est à l'étude, prévue ou écartée. Les trois réponses valent mieux que l'absence de réponse, y compris la dernière.

Ce que l'on ne peut pas affirmer : qu'une roadmap publique améliore la rétention d'un pourcentage donné. Aucune donnée publique solide ne l'établit, et les effets ci-dessus se mélangent au prix, au produit et à la concurrence. Le raisonnement défendable est plus modeste : l'invisibilité du travail a un coût certain, et une roadmap la réduit.

Relier une demande à un statut

C'est le mécanisme qui fait la différence entre une page décorative et une page utile.

Une roadmap qui liste des thèmes généraux ne répond à personne en particulier. Une roadmap où chaque élément est rattaché aux demandes qui l'ont motivé répond à tous ceux qui les avaient soutenues, d'un coup.

Concrètement, trois liens doivent exister :

• De la demande vers l'élément de roadmap, pour que celui qui a écrit retrouve son sujet.
• De l'élément vers les demandes, pour que le lecteur comprenne d'où vient la décision.
• De l'élément livré vers le changelog, pour fermer la boucle.

Quand ces liens existent, changer le statut d'un élément prévient tout le monde sans écrire un message. C'est ce que fait la feuille de route reliée au tableau des demandes de fonctionnalités.

Les statuts, et celui qu'on oublie

Le dernier est celui qu'on omet, et c'est le plus utile. Une roadmap qui ne contient que des choses à venir laisse toutes les autres demandes dans un état indéterminé : le client continue d'attendre, parfois des années, quelque chose qui a été écarté en interne depuis longtemps.

Les statuts doivent aussi pouvoir reculer. Un élément qui passe de « prévu » à « à l'étude », avec une phrase d'explication, coûte beaucoup moins cher qu'un élément affiché « prévu » pendant dix-huit mois.

Les promesses à ne pas faire

Une roadmap publique est lue comme un engagement, quelles que soient les réserves qui l'accompagnent.

Les dates. Une date publiée est retenue littéralement, et parfois utilisée pour justifier un achat. Le plus sûr est de ne pas en publier ; à défaut, un trimestre plutôt qu'un mois.

L'ordre comme promesse. Afficher une liste numérotée fait comprendre que le premier arrive d'abord. Si l'ordre reflète une priorité provisoire, il vaut mieux des colonnes de statut qu'un classement.

Le nombre de votes comme décision. Une roadmap ordonnée par voix crée l'attente que le sommet soit construit ensuite. Les votes sont un signal de fréquence parmi d'autres, comme le détaille la priorisation du feedback.

Inviter le feedback au bon endroit

Une roadmap publique est aussi un point de collecte, et c'est un usage souvent négligé.

Le lecteur d'un élément « à l'étude » est exactement la personne dont l'avis vaut le plus à ce moment-là : elle a le problème et elle n'a pas encore vu la solution. Un champ de commentaire sur l'élément, ou un lien vers la demande d'origine, récupère un contexte qu'aucune enquête n'obtiendrait aussi facilement.

C'est aussi le moment où l'on découvre qu'un élément recouvre deux besoins différents, avant d'avoir construit l'un des deux.

Ce qu'elle ne remplace pas

Une roadmap publique regarde en avant. Elle ne remplace pas le changelog, qui regarde en arrière et prouve que les choses sortent vraiment.

Elle ne remplace pas non plus une réponse individuelle quand quelqu'un signale un problème précis. Renvoyer un client mécontent vers une page publique est perçu comme une esquive, et à juste titre.

Enfin, elle ne remplace pas la décision de refuser. Une roadmap dont tout le contenu est « à l'étude » n'informe personne et repousse le travail d'arbitrage au lieu de le montrer.

Questions fréquentes

Faut-il rendre publique toute la roadmap ?

Non. Ce qui gagne à être public : ce qui est en cours, ce qui est prévu, ce qui est écarté et pourquoi. Les hypothèses non validées et les contraintes internes n'aident pas le lecteur à décider quoi que ce soit.

Que faire quand un élément est abandonné ?

Le déplacer en « non prévu » avec la raison, et le laisser visible un temps. Un élément qui disparaît sans explication est remarqué et interprété plus sévèrement que l'abandon lui-même.

Une roadmap publique aide-t-elle à vendre ?

Elle rassure sur la vitalité du produit, surtout pour un produit jeune. Elle devient un risque si un prospect achète en s'appuyant sur un élément qui n'arrive pas.

En quoi est-ce différent du building in public ?

Le building in public est une stratégie de communication qui englobe la manière de travailler en public. La roadmap publique est un artefact précis : la vue client de ce qui est décidé.

Pour aller plus loin

• Building in public : partager sa roadmap avec prudence
• Le changelog public, un vrai outil de confiance
• Roadmap produit : aligner les équipes sur la rétention

Relier chaque élément aux demandes qui l'ont motivé est ce qui rend la page utile. Voyez la feuille de route et les tarifs.