Chaque feuille de route SaaS porte la fierté des choses qui ont été construites et le silence sur les choses que personne n'utilise. La deuxième catégorie est généralement plus grande que la première et presque personne ne mesure sa taille. L'adoption des fonctionnalités est la mesure qui rend ce silence visible : elle indique quelle fraction de la base utilise réellement chaque chose que vous avez passé des mois à construire.
La question est inconfortable car la réponse est généralement faible. Les fonctionnalités qui ont consommé des quarts d'ingénierie sont touchées par une minorité de la base, parfois par personne d'autre que ceux qui les ont demandées lors de la réunion. Sans mesurer l’adoption, ce gaspillage se cache derrière le sentiment de progrès que procure le fait d’avoir livré ses produits. Le journal des modifications s'agrandit, le produit gonfle et la valeur par utilisateur ne bouge pas.
Quelles mesures d'adoption des fonctionnalités
L'adoption mesure la fraction d'utilisateurs, ou de comptes, qui utilisent une fonctionnalité donnée dans un laps de temps donné. Si une fonctionnalité est disponible pour mille comptes et que deux cents l'ont utilisée au cours du mois dernier, son adoption est de vingt pour cent. Le numéro est simple à décrire et révélateur à lire, car il expose la distance entre ce qui existe dans le produit et ce que le client intègre réellement dans son utilisation.
Il y a deux lectures utiles qui méritent d’être séparées. L'adoption généralisée explique le nombre de comptes qui utilisent cette fonctionnalité. L’adoption approfondie répond à l’intensité avec laquelle ceux qui y jouent l’utilisent réellement. Une ressource peut avoir une grande largeur et une faible profondeur, de nombreuses personnes l'ont essayée une fois et l'ont abandonnée, ou au contraire, peu de clients mais vivent à l'intérieur. Les deux dimensions racontent des histoires différentes et nécessitent des actions différentes.
La fenêtre de mesure compte autant que la fonctionnalité. L'adoption accumulée depuis le lancement gonfle avec le temps et cache l'abandon, car elle compte parmi les adoptants ceux qui l'ont utilisé une fois il y a des mois. L'adoption récente, au cours du dernier mois ou de la dernière semaine concernée, montre l'utilisation en direct. Pour la plupart des décisions, ce qui compte est de savoir si les gens l’utilisent maintenant, et non s’ils l’ont déjà essayé.
Pourquoi lier l'adoption à la fidélisation et aux revenus
L'adoption isolée est une curiosité. L'adoption croisée avec la fidélisation et les revenus est une stratégie. La question qui transforme cette mesure en outil de prise de décision est de savoir si ceux qui utilisent une certaine ressource restent plus longtemps, paient plus ou annulent moins que ceux qui ne l'utilisent pas. Lorsque vous répondez à cette question, vous découvrez quelles fonctionnalités sont des moteurs d’activité et lesquelles ne sont qu’un poids mort dont la maintenance coûte cher.
Ce croisement révèle généralement un motif clair. Il existe des ressources qui fonctionnent comme un point d'ancrage : les comptes qui les adoptent conservent bien au-dessus de la moyenne et s'annulent rarement, car cette ressource fait désormais partie de leur travail. L'identification de ces ressources d'ancrage modifie l'ensemble de l'intégration, car attirer de nouveaux clients vers elles cesse d'être facultatif et devient une priorité du produit, directement liée à ce dont j'ai discuté dans activation utilisateur.
Du côté des revenus, l’adoption détermine la stratégie de packaging et de tarification. Une fonctionnalité avec une forte adoption et une forte corrélation avec la permanence est candidate à faire partie du plan principal, car elle soutient la fondation. Une ressource utilisée par peu de comptes, mais par ceux qui ont la valeur la plus élevée, est candidate pour faire partie d'un plan supérieur ou d'un module payant. L’adoption vous indique où se situe votre volonté de payer, et l’ignorer revient à établir un prix dans le noir. Ce pont apparaît fortement lorsqu'il s'agit d'expansion et vente incitative.
Le risque de construire ce que personne n'adopte
Le coût d’une ressource ne s’arrête pas au moment où elle est livrée, il commence là. Chaque fonctionnalité du produit doit être maintenue, testée, documentée, prise en charge et prise en compte lors de chaque modification future. Une fonctionnalité dont l'adoption est quasi nulle n'est pas neutre, c'est une responsabilité permanente qui vole la capacité d'ingénierie et ajoute de la complexité que chaque utilisateur paie sous la forme d'un produit plus déroutant. Ce que personne n’utilise continue à gêner ceux qui utilisent le reste.
La cause profonde de ce gaspillage est souvent la construction sur ordre plutôt que sur des preuves. Un gros client demande, promet des ventes, l'ingénierie tient ses promesses, et la ressource est née au service d'un seul compte et d'aucun autre. Sans mesurer l’adoption après le lancement, personne ne boucle le cycle pour découvrir qu’il ne s’est pas généralisé. L'entreprise continue d'empiler des fonctionnalités avec la conviction que plus de fonctionnalités signifie plus de valeur, alors qu'elles signifient souvent plus de maintenance et moins de clarté.
Mesurer l’adoption introduit la discipline manquante : celle d’évaluer ce qui a été construit au même titre qu’un investissement. La fonctionnalité lancée est une hypothèse sur la valeur, et l'adoption est le test de cette hypothèse. Lorsque le test échoue systématiquement, il faut prendre des décisions réfléchies : améliorer la découverte des fonctionnalités, la repositionner ou la supprimer du produit pour réduire le poids. Le retrait de fonctionnalités est un acte de santé produit que peu d’équipes pratiquent, précisément parce que peu mesurent l’adoption au point de la justifier.
Comment mesurer l'adoption sans se noyer dans les événements
L’erreur technique la plus courante consiste à tout instrumenter et à ne rien analyser. Les équipes activent le suivi à chaque clic, accumulent des milliers d'événements et se perdent dans une mer de données sans poser de questions. Une adoption utile commence par définir, pour chaque fonctionnalité importante, quel événement représente l'utilisation réelle, non pas l'ouverture de l'écran, ni le survol de la souris, mais l'action qui signifie que le client a extrait la valeur de cette fonctionnalité. Cette découpe est ce qui sépare la mesure de la collecte.
Il convient de privilégier la mesure par des ressources qui portent un enjeu stratégique. Vous n'avez pas besoin d'adoption, vous avez besoin de chaque bouton. Il nécessite l’adoption fiable de fonctionnalités qui justifient un investissement important, celles qui différencient le produit sur le marché et celles qui prennent en charge des plans supérieurs. Concentrer l'instrumentation là où il y a une décision à prendre donne bien plus que de répartir le suivi sur l'ensemble de l'interface et de ne jamais regarder le résultat.
L’analyse gagne en puissance lorsqu’elle segmente. L'adoption moyenne cache tout. L'adoption par segment de clientèle, par taille de compte, par forfait, par cohorte d'entrée, révèle où la fonctionnalité est populaire et où elle ne le fait pas. Une fonctionnalité avec une faible adoption globale peut avoir une adoption très élevée dans le segment pour lequel elle a été conçue, ce qui change complètement le verdict à son sujet. L'examen du nombre par tranche est ce qui transforme l'adoption du score en diagnostic et le relie à la lecture de fréquence que j'ai détaillée dans DAU, MAU et rigidité.
Adoption comme filtre de feuille de route
Lorsque l’adoption entre dans le processus produit, elle change la conversation sur ce qu’il faut construire ensuite. La question n’est plus de savoir quelles nouvelles ressources s’inscrivent dans le trimestre mais commence à inclure la part de ce qui existe déjà qui est utilisée. Un produit avec de nombreuses fonctionnalités à faible adoption n'a pas besoin de fonctionnalités supplémentaires, il a besoin que celles qui existent soient découvertes, améliorées ou supprimées. La métrique force cette autocritique avant chaque nouveau cycle de construction.
L'adoption sert également de preuve pour défendre les priorités face à la pression de demandes ponctuelles. Lorsque les ventes ou un gros client proposent une fonctionnalité, le fait de disposer de données d'adoption provenant de commandes passées similaires modifie la négociation. Vous pouvez désormais dire, avec des chiffres, combien de fois les ressources demandées par un compte ont fini dans le cimetière à usage nul. Cela ne signifie pas ne jamais exécuter les commandes, cela signifie les exécuter avec les yeux ouverts sur l'histoire.
Si votre entreprise ne peut pas dire, pour les cinq fonctionnalités les plus coûteuses qu'elle a construites au cours de l'année dernière, quelle fraction de la base les utilise aujourd'hui, la feuille de route est décidée par l'intuition et par celui qui crie le plus fort. Mesurer l’adoption ne permet pas à lui seul de décider quoi construire, mais permet également de sortir la décision de l’obscurité. Commencez par les fonctionnalités dans lesquelles vous avez le plus investi, découvrez qui les utilise réellement et dans quelle mesure elles tiennent la base, et laissez ce portrait éclairer la suite du produit.
A lire aussi
- Activation des utilisateurs en SaaS : le moment où le client comprend pourquoi il a payé
- DAU, MAU et collant : quand la raison entre eux dit quelque chose et quand elle trompe -Churn in SaaS : la fuite qui décide si vous grandissez ou si vous remplacez
- Expansion et upsell en SaaS : une croissance qui vient de l'intérieur de la base que vous avez déjà
- LTV en SaaS : le nombre que la rétention crée et le désabonnement détruit
- Désabonnement des revenus versus désabonnement des clients : pourquoi perdre un gros n'est pas perdre un petit