Comment annoncer une nouvelle fonctionnalité (sans silence)

La plupart des annonces de fonctionnalités meurent dans un canal que personne ne lit deux fois : un tweet qui défile, un email du jour de sortie enterré sous les douze autres qu’une abonnée a reçus cette semaine-là, un message Slack dans un canal que la moitié de l’équipe a coupé il y a des mois. La fonctionnalité est sortie. Presque personne parmi celles qui l’auraient utilisée ne l’a su. Corriger ça tient moins à écrire une meilleure annonce qu’à choisir le bon canal pour la bonne lectrice, et à atteindre directement celles qui l’ont explicitement demandée plutôt que de compter sur le fait qu’elles remarquent une annonce générale.

Où une nouvelle fonctionnalité devrait-elle vraiment être annoncée ?

À plus d’un endroit, parce que « tout le monde lit le même canal » n’est jamais vrai. Une entrée de changelog ou de flux sert la lectrice qui vérifie à son propre rythme et veut le registre permanent et daté. Un avis in-app sert la lectrice déjà en train d’utiliser le produit qui utiliserait la fonctionnalité aujourd’hui si elle savait qu’elle existe. L’email sert la lectrice qui n’est pas actuellement dans le produit mais reviendrait pour la bonne mise à jour. Les réseaux sociaux servent une portée au-delà des utilisatrices existantes, avec presque aucun ciblage.

Aucun des quatre ne suffit seul. Le changelog est le seul document qui devrait porter chaque release quelle que soit sa taille, parce que c’est le registre vers lequel tout le reste renvoie ; les trois autres sont une amplification ajoutée par-dessus, choisie selon l’ampleur réelle de la fonctionnalité.

Que devrait dire l’annonce en premier ?

Le résultat, pas le mécanisme. « Nous avons ajouté une couche de cache à l’endpoint des rapports » décrit ce que l’équipe a construit. « Les rapports se chargent désormais en moins d’une seconde » décrit ce qui a changé pour la lectrice, et c’est la phrase qui obtient le clic, parce qu’elle répond à « qu’est-ce que ça m’apporte » dans la première proposition plutôt que la troisième. Le mécanisme appartient à l’entrée de changelog ou à la page de détail, pas au titre.

Du concret avant des adjectifs. « Une expérience de rapports plus rapide et plus puissante » ne dit rien à la lectrice sur quoi agir ; « les rapports se chargent désormais en moins d’une seconde et peuvent être filtrés par statut » lui dit exactement ce qui a changé et quoi essayer. La seconde version paraît aussi plus crédible, parce qu’une affirmation vague sonne exactement comme sonne un texte marketing quand il n’y a rien de concret à dire.

En quoi diffère-t-elle d’un email de mise à jour produit ?

Elles se recoupent sans être identiques. Email de mise à jour produit couvre le canal email spécifiquement, y compris la cadence, les objets, et quand un digest bat un envoi ponctuel. Une annonce de nouvelle fonctionnalité est l’événement sous-jacent ; l’email est l’un des quatre canaux ci-dessus qui pourrait la porter, choisi quand la fonctionnalité est assez grande pour justifier un envoi dédié plutôt que de voyager dans le prochain digest. Une petite fonctionnalité mérite une entrée de changelog et peut-être un avis in-app. Une fonctionnalité importante mérite les quatre canaux, coordonnés dans le temps.

Comment atteindre les personnes précises qui l’ont demandée ?

C’est l’annonce au meilleur rapport effort/impact, et presque toutes les équipes la sautent. Si dix clientes ont demandé une fonctionnalité par son nom, ces dix personnes méritent une note directe et personnelle au moment où elle sort, indépendamment de toute annonce plus large qui part par ailleurs. Boucler la boucle de feedback avec le client couvre le mécanisme en entier ; le résumé ici est que cela ne fonctionne que si la demande d’origine est restée liée à la demandeuse, ce qui relève plus d’un problème de suivi que d’un problème d’annonce. Chez changeloop, quand un retour via le widget est devenu une issue GitHub et que la pull request mergée la ferme (fixes #142), approuver l’entrée de changelog poste une seule fois le commentaire « Shipped —

Comment écrire l’entrée elle-même ?

La même discipline que toute autre entrée de notes de version : commencer par ce que la lectrice peut désormais faire, poursuivre avec la configuration nécessaire, sauter la justification interne. Comment rédiger des notes de version couvre la méthode complète ; une annonce de nouvelle fonctionnalité est le cas aux enjeux les plus élevés, parce que c’est l’entrée la plus susceptible d’être capturée en screenshot, transférée, et lue par quelqu’un qui n’a jamais vu le changelog du produit.

Quand ne faut-il pas annoncer largement ?

Quand la fonctionnalité est encore en déploiement vers un sous-ensemble de comptes, qu’il s’agit vraiment d’une bêta, ou qu’elle est tarifée ou verrouillée de telle façon que neuf lectrices sur dix d’une annonce large ne pourraient pas encore l’utiliser. Une annonce large pour une fonctionnalité que neuf lectrices sur dix ne peuvent pas utiliser se lit comme un appât, et grille la confiance dans la prochaine annonce plus qu’elle ne crée d’enthousiasme dans celle-ci. La solution n’est pas le silence, c’est la portée : informer directement les comptes éligibles et retenir les canaux larges jusqu’à ce que la disponibilité rattrape l’annonce.

FAQ

Chaque nouvelle fonctionnalité mérite-t-elle sa propre annonce ? Chacune mérite une entrée de changelog. Seules celles assez significatives pour changer la façon dont quelqu’un utilise le produit, ou explicitement demandées par leur nom, méritent les canaux plus larges comme l’email ou les réseaux sociaux.

Quel est le meilleur canal pour une petite fonctionnalité ? Le changelog seul, plus un avis in-app si la fonctionnalité est découvrable dans un flux où l’utilisatrice se trouve déjà. L’email et les réseaux sociaux valent la peine pour des fonctionnalités qui justifient de demander de l’attention.

Comment annoncer une fonctionnalité aux personnes qui l’ont spécifiquement demandée ? Garder la demande liée à la demandeuse dès son enregistrement, puis notifier individuellement à la sortie, séparément de toute annonce plus large. Une étiquette de statut partagée que la demandeuse peut vérifier elle-même réduit aussi le nombre de messages individuels nécessaires en premier lieu.

Une annonce de fonctionnalité a-t-elle besoin d’un screenshot ? Pour tout ce qui est visuel, oui ; une fonctionnalité décrite mais non vue est sautée bien plus souvent qu’une dont les lectrices peuvent voir un aperçu. Pour une API ou une capacité backend, un court exemple de code fait le même travail qu’un screenshot pour un changement d’interface.

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 : Exemples de changelog, Documentation développeurs