Le responsable produit livre une fonction. La fonction est censée résoudre un problème des clients et favoriser la fidélisation.
Deux semaines après le lancement : la fonction réduit-elle les départs ? Plus de clients l'utilisent-ils ? Les clients passent-ils plus de temps dans la fonction ?
Sans tableau de bord produit, le responsable produit attend six semaines le rapport mensuel pour voir l'impact de la fonction. D'ici là, les retours des clients sont refroidis. Impossible d'itérer.
Avec un tableau de bord produit, le responsable produit voit au bout de deux semaines : l'adoption de la fonction est de cinq pour cent (l'objectif était vingt pour cent à la semaine deux). Le problème saute aux yeux. Le responsable produit enquête. Il découvre que la fonction est difficile à trouver. Il ajoute un message d'accueil. L'adoption passe à quinze pour cent à la semaine quatre.
Les tableaux de bord produit : adoption et engagement des fonctions
Le taux d'adoption d'une fonction
Fonction lancée il y a deux semaines. Utilisateurs éligibles : dix mille. Utilisateurs qui ont utilisé la fonction : cinq cents. Taux d'adoption : cinq pour cent. L'objectif était vingt pour cent à la semaine quatre. Actuellement en retard. Une enquête s'impose.
L'engagement avec la fonction
Sur les cinq cents utilisateurs qui ont essayé la fonction, combien l'utilisent chaque jour ? Deux cents. Combien l'utilisent chaque semaine ? Trois cents. Combien l'ont abandonnée ? Deux cents. Taux d'engagement : quarante pour cent par jour, soixante pour cent par semaine, quarante pour cent d'abandon. L'abandon est trop élevé. La fonction n'accroche pas.
Le temps passé dans la fonction
La session moyenne dans la fonction dure deux minutes. Avant la fonction, la durée moyenne d'une session sur le site était de dix minutes. La fonction détourne les utilisateurs d'autres fonctions. Est-ce voulu ? La fonction a-t-elle remplacé une ancienne fonction ou s'ajoute-t-elle ?
L'impact sur la fidélisation
Clients qui ont adopté la fonction : huit pour cent de départs par mois. Clients qui n'ont pas adopté la fonction : douze pour cent de départs par mois. La fonction marche. Amélioration de quatre points de pourcentage. Pour une base de mille clients, cela fait quarante clients de moins qui partent chaque mois. Quarante fois cinquante (valeur moyenne d'un client) donne deux mille de chiffre d'affaires sauvé par mois.
Les tableaux de bord d'exploitation : santé et performance du système
La disponibilité du système
Le site a été en ligne 99,95 pour cent du temps la semaine dernière. L'objectif est de 99,99 pour cent. Nous sommes en dessous de l'objectif. Deux pannes : une de dix minutes, une de quinze minutes. Ensemble, vingt-cinq minutes d'indisponibilité. Qu'est-ce qui a causé les pannes ? Peut-on les éviter ?
Le temps de réponse
Le temps de réponse moyen de l'API est de deux cents millisecondes. Le temps de réponse P95 est de cinq cents millisecondes (95 pour cent des requêtes sont plus rapides, cinq pour cent sont plus lentes). Le P99 est d'une seconde. Des temps de réponse lents arrivent de temps en temps. Sont-ils acceptables ?
Le taux d'erreurs
Un pour cent des requêtes d'API ont renvoyé une erreur. En hausse par rapport à zéro virgule cinq pour cent la semaine dernière. Le taux d'erreurs a doublé. Qu'est-ce qui a changé ? Une requête de base de données est plus lente. Les temps de réponse ont augmenté. Les clients dépassent le délai et réessaient. Une enquête s'impose.
Le pool de connexions à la base de données
Le pool compte cent connexions. Actuellement cent sont ouvertes (utilisation complète). Plus aucune connexion disponible. Si une requête de plus arrive, elle est mise en file d'attente. L'utilisateur attend. Le pool est à saturation. Il faut augmenter le pool ou réduire l'usage.
Le taux de réussite du cache
Le cache est sollicité avec succès cinquante pour cent du temps. Cinquante pour cent du trafic n'a pas besoin de requête en base de données. Un taux d'échec du cache de cinquante pour cent est acceptable pour la plupart des sites. Sous quarante pour cent, la base de données est surchargée. Au-dessus de soixante-dix pour cent, vous en faites trop avec le cache.
Un exemple réel : le tableau de bord produit et exploitation d'un SaaS
Indicateurs produit
Nouvelle fonction de tableau de bord : lancée au mois un. Utilisateurs éligibles : cinq mille (clients avec plus de dix points de données). Utilisateurs qui ont créé un tableau de bord : mille. Taux d'adoption : vingt pour cent. Objectif atteint.
Sur les mille qui ont créé un tableau de bord : Actifs chaque jour : six cents. Bon engagement. Actifs chaque semaine : neuf cents. La plupart l'utilisent au moins chaque semaine. Abandons : cent. Dix pour cent de départs.
Impact sur la fidélisation : les clients avec des tableaux de bord actifs ont deux pour cent de départs par mois. Les clients sans tableaux de bord ont quatre pour cent de départs par mois. Le tableau de bord évite deux points de départs. Pour une base de mille clients, cela fait vingt clients. À cent dollars de valeur mensuelle par client, cela fait deux mille de chiffre d'affaires sauvé par mois. Vingt-quatre mille par an.
Indicateurs d'exploitation
Disponibilité le mois dernier : 99,92 pour cent. Objectif : 99,95 pour cent. Nous avons manqué l'objectif.
Pannes : Un incident : dix minutes, traitement des paiements hors service. Cause : la bascule de la base de données a pris trop de temps. Un incident : quinze minutes, pic de dépassements de délai de l'API. Cause : afflux de trafic et requête de base de données lente.
Temps de réponse : Moyenne : cent cinquante millisecondes. Bien. P95 : trois cents millisecondes. Acceptable. P99 : une seconde. C'est trop élevé. Un pour cent des clients attendent une seconde. À optimiser.
Taux d'erreurs : zéro virgule huit pour cent. En hausse par rapport à zéro virgule quatre pour cent il y a deux semaines. L'enquête montre : les erreurs de traitement des paiements ont augmenté parce que le prestataire de paiement a eu une panne la semaine dernière (pas notre faute), les erreurs d'API ont augmenté parce que nous avons déployé une modification de code qui a cassé un point d'accès (notre faute).
Base de données : Temps moyen des requêtes : trente millisecondes. Utilisation du pool de connexions : quatre-vingts pour cent. Sain. Taux de requêtes lentes : zéro virgule deux pour cent. Acceptable.
Taux de réussite du cache : soixante-cinq pour cent. Sain.
Relier les tableaux de bord produit et d'exploitation
L'adoption d'une fonction dépend de la performance du système. Si le système est lent, l'adoption en souffre. La nouvelle fonction de tableau de bord a une faible adoption. Consultez le tableau de bord d'exploitation. Le temps de réponse P99 est d'une seconde. Les utilisateurs subissent un décalage à l'ouverture du tableau de bord. Ajoutez à l'enquête : la lenteur provoque-t-elle la faible adoption ? Si oui, optimisez d'abord la performance du système. Puis mesurez de nouveau l'adoption.
La performance du système est mesurée en disponibilité, pas en impact sur les fonctions. Mais l'impact des fonctions dépend de la disponibilité. Reliez les deux tableaux de bord. Quand les indicateurs d'exploitation se dégradent, les indicateurs produit se dégradent aussi.
Questions fréquentes
À quelle fréquence le responsable produit doit-il vérifier l'adoption d'une fonction ?
Première semaine : chaque jour. La fonction vient d'être lancée, la courbe d'adoption est la plus raide. Il faut repérer tôt les problèmes. Semaines deux à quatre : trois fois par semaine. La courbe d'adoption s'aplatit. Des mises à jour hebdomadaires suffisent. Après le premier mois : chaque semaine. L'adoption a atteint un plateau ou croît régulièrement. Une vérification hebdomadaire suffit. Exception : si la fonction est critique ou si l'adoption initiale est sous l'objectif, le suivi quotidien continue jusqu'à ce que le problème soit résolu. Avec le créateur de site web de WEMASY, vous pouvez le mettre en place directement sur votre site.
Quel taux d'adoption d'une fonction est acceptable selon la semaine ?
Semaine un : cinq à quinze pour cent (les gens essaient). Semaine deux : dix à trente pour cent (le bouche-à-oreille se répand). Premier mois : vingt à cinquante pour cent (taux stabilisé). Cela varie selon les fonctions. Des fonctions de jeu peuvent atteindre quatre-vingt-dix pour cent d'adoption. Des fonctions de conformité n'atteindront peut-être que dix pour cent. L'objectif doit reposer sur le segment d'utilisateurs et l'importance de la fonction, pas sur une référence générique. Avant le lancement, décidez : cette fonction est-elle pour tout le monde ou seulement pour un segment ? Cela détermine l'objectif.
Comment distinguer adoption et engagement ?
L'adoption, c'est essayer la fonction (l'ont-ils utilisée au moins une fois). L'engagement, c'est l'utiliser de façon répétée (chaque jour, chaque semaine, chaque mois). Une fonction peut avoir une forte adoption et un faible engagement (tout le monde a essayé, peu sont restés). Une fonction peut avoir une faible adoption et un fort engagement (peu ont essayé, mais ceux-là ont adoré). Les deux indicateurs comptent. Forte adoption et fort engagement, c'est le succès. Un faible engagement signifie que la fonction ne résout pas un vrai problème. Une faible adoption signifie un problème de visibilité.
Le tableau de bord produit doit-il inclure les retours des clients ou seulement des indicateurs ?
Incluez les deux. Les indicateurs disent ce que font les clients. Les retours disent pourquoi. Cinq cents utilisateurs ont abandonné la fonction (indicateur). Les retours disent « la fonction est difficile à trouver » ou « la fonction ne résout pas mon problème » (pourquoi). Des indicateurs sans retours sont incomplets. Ajoutez une section de retours qui montre les trois principales raisons de départ ou d'abandon d'après les tickets de support et les enquêtes. Mise en œuvre : ajoutez un champ de commentaire à la fonction. Chaque semaine : lisez les vingt principaux commentaires d'utilisateurs et classez-les par thèmes. Rapportez les thèmes sur le tableau de bord.
Comment fixer des objectifs de disponibilité et de temps de réponse ?
Fondez les objectifs sur l'impact pour les clients et les standards du secteur. Pour le paiement d'une boutique en ligne : disponibilité de 99,9 pour cent, temps de réponse sous deux secondes. Pour un site vitrine : disponibilité de 99 pour cent, temps de réponse sous trois secondes. Pour des outils internes : disponibilité de 95 pour cent, temps de réponse sous cinq secondes. Plus le service est critique, plus l'objectif est exigeant. En fixant l'objectif, sachez quel niveau d'investissement il demande. Une disponibilité de 99,99 pour cent (quatre neuf) coûte trois à quatre fois plus qu'une disponibilité de 99 pour cent (deux neuf). Assurez-vous que l'objectif vaut son coût.
Le tableau de bord d'exploitation doit-il déclencher des alertes ou seulement afficher un statut ?
Les deux. Le tableau de bord montre le statut actuel. Les alertes se déclenchent quand des seuils sont franchis. Si le taux d'erreurs dépasse un pour cent pendant cinq minutes, l'alerte se déclenche. L'alerte va à l'ingénieur d'astreinte qui enquête. Le tableau de bord sert à la surveillance pendant les heures normales. L'alerte sert en dehors des heures de travail ou dans les situations critiques. Aucun des deux ne suffit seul. Un tableau de bord sans alertes veut dire que les problèmes sont découverts pendant les heures de travail. Une alerte sans tableau de bord veut dire que l'équipe ne voit pas une dégradation lente avant le déclenchement de l'alerte. Utilisez les deux ensemble.