Votre changelog est un outil de conversion que vous ignorez

La plupart des changelogs sont écrits pour une seule audience : les utilisateurs existants qui veulent savoir ce qui a changé. Ce n'est pas le bon angle.

Votre changelog est lu par trois groupes. Les utilisateurs actifs qui veulent savoir ce qui est nouveau. Les utilisateurs inactifs ou partis qui décident de revenir. Les prospects qui évaluent votre produit et cherchent la preuve qu'il est activement maintenu.

Le premier groupe est celui pour qui vous écrivez. Les deuxième et troisième groupes sont ceux pour qui vous devriez écrire.

La question du prospect

Avant de s'inscrire à un SaaS, la plupart des gens consultent deux pages : la tarification et le changelog. La page de tarification leur dit ce qu'ils vont payer. Le changelog leur dit si le produit est vivant.

Un changelog dont la dernière entrée date de six mois signale que le produit est abandonné ou stagnant. Un changelog mis à jour la semaine dernière signale que quelque chose se passe, que l'équipe livre, que les problèmes sont résolus.

Les prospects ne cherchent pas des détails techniques. Ils veulent répondre à une seule question : "Ce produit s'améliore-t-il ?" Chaque entrée qui dit qu'un vrai problème a été corrigé, qu'une vraie fonctionnalité a été ajoutée, ou qu'une vraie demande utilisateur a été implémentée répond oui à cette question.

Écrivez votre changelog pour la personne qui n'est pas encore inscrite. Elle a besoin d'une histoire de progression, pas d'un journal de commit.

L'angle réengagement

Les utilisateurs inactifs sont l'opportunité de conversion la plus sous-estimée en SaaS. Ils comprennent déjà votre produit. Ils l'ont voulu suffisamment pour s'inscrire. Quelque chose les a fait décrocher : une fonctionnalité manquante, un mauvais timing, ou simplement la vie.

Un changelog bien rédigé vous donne une raison de les recontacter avec quelque chose de concret : "On a livré ce que vous attendiez." Même sans campagne email, les utilisateurs qui reviennent consulter votre changelog sont des utilisateurs qui reconsidèrent. Assurez-vous qu'ils trouvent quelque chose qui en vaut la peine.

Ce qu'il faut écrire

Écrivez sur ce qui intéresse les utilisateurs.

Nouvelles fonctionnalités. Une phrase décrivant la fonctionnalité, une phrase décrivant le problème qu'elle résout. "Vous pouvez maintenant filtrer les retours par date. Trouver ce que les utilisateurs ont dit la semaine dernière ne nécessite plus de tout parcourir."

Améliorations significatives. Avant et après, brièvement. "L'export gère désormais les projets avec 50 000 entrées ou plus sans délai d'attente."

Corrections de bugs qui ont touché assez de gens. "Corrigé : le widget ne se chargeait pas sur les pages avec une politique de sécurité du contenu stricte."

Choses demandées par les utilisateurs. Créditez-les. "Ajout des mises à jour en masse, demandé par 22 utilisateurs." Cela ferme la boucle en public et montre que les retours mènent à des changements.

Ce qu'il faut éviter

Les refactorisations internes. Les mises à jour de dépendances. Les changements d'infrastructure que les utilisateurs ne voient pas. Les entrées vagues comme "améliorations de performance" ou "corrections diverses."

Le test : si un utilisateur lit cette entrée, comprendrait-il pourquoi s'en préoccuper ? Si non, réécrivez-la ou ne la publiez pas. Votre changelog n'est pas un journal de développement. C'est un récit produit.

Le format qui fonctionne

Un changelog court se lit. Un long se survole puis se ferme.

Chaque entrée doit faire une à trois phrases au maximum. Utilisez des catégories claires : Nouveau, Amélioré, Corrigé. Écrivez du point de vue de l'utilisateur ("Vous pouvez maintenant exporter en CSV directement depuis le tableau de bord") plutôt que de l'ingénieur. Liez vers la fonctionnalité concernée quand c'est possible.

La cadence compte plus que la longueur. Une mise à jour par semaine, même deux ou trois points, vaut mieux qu'un dump mensuel de 20 éléments. La livraison continue est le signal. Elle dit au lecteur que le travail est continu, pas publié en lots.

La condition en amont

Les meilleurs changelogs viennent des meilleurs systèmes de feedback. Quand vous savez ce qui frustre les utilisateurs, vous le corrigez. Quand vous le corrigez, vous avez quelque chose de réel à écrire. Quand les utilisateurs lisent que leur problème a été traité, ils restent et en parlent autour d'eux.

C'est la boucle centrale de la croissance bouche-à-oreille pour les petits SaaS : écouter les utilisateurs, résoudre leurs problèmes, leur dire que vous l'avez fait. Un outil comme Palmframe gère l'étape d'écoute automatiquement. Le changelog est l'étape "leur dire." Ne la sautez pas.