Résumé : l'analyse produit désigne le processus étudiant les interactions des utilisateurs avec un produit ou un service. Elle permet aux équipes produit de suivre, de visualiser et d'analyser les données d'engagement des utilisateurs et comportementales. Les équipes utilisent ces informations pour améliorer et optimiser un produit ou un service.
En tant que gestionnaires de produit, nous saisissons toutes les opportunités de mieux connaître nos clients, car comprendre leurs besoins est essentiel pour développer des produits utiles. Cela implique de réaliser des entretiens client et des enquêtes, et d'examiner les analyses internes au produit. Les données que nous obtenons par le biais des analyses produit nous indiquent comment les utilisateurs utilisent le produit, et non ce qu'ils souhaitent faire, comment ils pensent l'utiliser, ou même comment nous pensons qu'ils l'utilisent.
Le développement diffère en ce qu'il utilise la méthodologie Agile (qui pourrait certainement bénéficier à la construction de maisons). Agile permet à plusieurs équipes de réagir rapidement aux changements. Alors, comment Agile, une méthode basée sur une livraison fréquente et continue, peut-elle coexister avec une planification à long terme et à grande échelle ? Est-il possible d'établir une prévision réaliste sur une longue période, sachant que la seule constante est le changement ?
En tant que responsable produit, des questions comme « Combien de temps les utilisateurs passent-ils chaque jour sur le produit ? », « Quelles actions exécutent-ils le plus ? » ou « Quelles fonctionnalités sont les moins utilisées ? », sont extrêmement précieuses pour comprendre vos utilisateurs et nous donner des pistes pour améliorer leur expérience. Dans cet article, j'expliquerai ce qu'est l'analyse produit et pourquoi vous devriez l'utiliser, comment bien comprendre vos utilisateurs de manière à rembourser la « dette empathique » et comment orienter le développement de nouveaux produits grâce aux analyses.
C'est parti !
Essayez Jira Product Discovery gratuitement
Établissez les priorités, collaborez, proposez de nouvelles idées de produits et maximisez votre impact.
Qu'est-ce que l'analyse produit ?
L'analyse produit désigne le processus étudiant les interactions des utilisateurs avec un produit ou un service. Elle permet aux équipes produit de suivre, de visualiser et d'analyser les données d'engagement des utilisateurs et comportementales. Les équipes utilisent ces informations pour améliorer et optimiser un produit ou un service.
Pour développer une compréhension quantitative de l'utilisation de votre produit par les utilisateurs, vous devez d'abord vous appuyer sur les analyses produit. L'idée est de déclencher un événement pour toutes les actions éventuelles dans votre produit, afin d'obtenir une vue agrégée de l'utilisation d'une fonctionnalité et de la fréquence d'utilisation. Par exemple, si vous souhaitez déterminer le nombre de fois qu'un utilisateur clique sur un bouton spécifique, vous pourriez déclencher un événement appelé « big-red-button.click ». De là, vous pouvez voir les fonctionnalités à retravailler et les plus importantes, et utiliser ces informations pour hiérarchiser les changements.
Une multitude de solutions vous offrent un framework pour ajouter des événements d'analyse et les suivre. Consultez Google Analytics ou KISSmetrics pour commencer.
Chez Atlassian, nous avons essayé de faire en sorte que tout le monde puisse accéder aux données et gérer ses propres requêtes et rapports le plus simplement possible. Nous utilisons certains outils développés en interne pour proposer ces services, mais les outils Google Analytics vous permettent également de vous lancer. Par conséquent, tout le monde, des développeurs aux responsables produit, s'est mis à poser des questions sur l'utilisation et à essayer de comprendre l'impact de ce que nous développions.
La « dette empathique », un nouveau type de dette
Testons ce nouveau terme : « dette empathique ».
L'analyse interne au produit peut vous aider à rembourser votre dette empathique de deux façons : avec un feedback qualitatif recueilli lors d'activités telles que les tests de concepts et les entretiens avec les clients ; et avec des données quantitatives recueillies dans le produit grâce à des méthodes comme l'analyse produit et les enquêtes NPS.
À titre d'exemple, Confluence existe depuis assez longtemps maintenant, et dispose de nombreuses fonctionnalités pas ou peu analysées. Parmi elles, le tableau de bord, qui est le premier contact de la plupart des utilisateurs avec Confluence. Nous avons obtenu du feedback sur le tableau de bord lors d'entretiens avec des clients, mais nous ne disposions pas de tous les outils d'analyse produit nécessaires pour vraiment comprendre son utilisation d'un point de vue quantitatif. Nombre de nos questions restaient sans réponse, notamment :
- Dans quelle mesure le tableau de bord est-il utilisé ? Combien de fois le tableau de bord est-il consulté au cours d'une session Confluence classique ?
- À quelles fins le tableau de bord est-il utilisé exactement ? Le flux Toutes les mises à jour ? Le flux Populaire ? L'accès à un espace ?
- Quelles fonctionnalités les utilisateurs souhaitent-ils voir sur le tableau de bord ? Pouvons-nous déterminer les principaux points à couvrir en fonction de ce que font les utilisateurs après avoir consulté le tableau de bord ?
Nous devions apporter des réponses à ces questions fondamentales avant de nous lancer dans la modification d'une des pages les plus visitées de Confluence. Si vous ne disposez pas d'analyses dans votre produit, ou même d'une fonctionnalité spécifique que vous cherchez à modifier, vous êtes dans le même cas, et vous feriez mieux d'être prudent dans vos prises de décisions. C'est le moment de rembourser cette dette empathique !
Lors des tests de notre tableau de bord, nous avons appris que l'une des actions les plus fréquemment exécutées sur le tableau de bord était l'affichage des « pages favorites ». C'était une découverte essentielle, à laquelle nous n'avions pas pensé dans notre hypothèse de base. Ce qui permet de dégager l'enseignement clé suivant : remboursez votre dette empathique dès que possible. Si votre produit n'intègre pas d'analyses, ajoutez-les au plus vite et utilisez les données pour des décisions produit plus éclairées. Sinon, vous avancez à l'aveugle. Et souvenez-vous que les analyses ne mentent pas ! Elles nous montrent exactement comment les utilisateurs utilisent le produit, mais essayez de creuser davantage et de les utiliser pour comprendre les réels besoins des utilisateurs.
Testez les fonctionnalités de demain dès aujourd'hui
Si les analyses produit sont précieuses pour comprendre comment les utilisateurs exploitent les fonctionnalités existantes, elles sont également très utiles pour tester de nouvelles fonctionnalités et expériences. Si vous visez un degré d'utilisation spécifique pour votre fonctionnalité, les analyses produit vous permettront d'atteindre ce vieux principe Agile : « échouer rapidement et itérer jusqu'à réussir ».
Le processus que nous suivons en général ressemble à ce qui suit :
- Définissez une hypothèse claire pour un changement produit, par exemple : « En augmentant la taille de la zone de commentaire, nous prévoyons une augmentation de 5 % des commentaires. »
- Faire un build de ce changement de la façon la plus avantageuse possible, y ajouter toutes les données analytiques nécessaires, qui nous permettront de vérifier notre hypothèse.
- Déployer le changement auprès d'un sous-ensemble de clients dans un test A/B.
- Nous tourner les pouces pendant que nous attendons les résultats.
- Analyser les résultats avec l'aide d'un analyste dans les cas plus complexes et déterminer si le changement a réussi.
Nous avons fini par concevoir trois tableaux de bord très « spécifiques », chacun mettant en avant un cas d'usage et un ensemble de comportements différents. Nous les avons soumis à ce processus (même si notre hypothèse était un peu plus compliquée), et nous avons obtenu d'excellents résultats. Toutefois, nous avons découvert (parfois à nos dépends) certains pièges auxquels vous devez être attentif avant de tester de nouvelles fonctionnalités de cette façon.
- Il n'y a rien de pire que d'arriver au terme d'une expérience et de réaliser que vous ne disposez pas de tous les événements nécessaires… Essayez d'effectuer votre analyse avant de réaliser l'expérience sur la base de quelques données factices, de sorte à détecter rapidement les lacunes.
- Définir une hypothèse peut prendre du temps, mais il est essentiel que vous en ayez une et que vous soyez certain de pouvoir la prouver ou la réfuter avec l'analyse produit que vous réaliserez avant le lancement. Procéder en premier lieu à une analyse sur des données factices vous aidera également à tester cela.
- Assurez-vous de réaliser vos tests sur un panel suffisamment large d'utilisateurs et sur une période assez longue. Vos résultats doivent être significatifs d'un point de vue statistique.
- Soyez prêt à rejeter les mauvaises idées ! Comme déjà évoqué, vous souhaitez tester les fonctionnalités à moindre coût et exécuter ces tests le plus vite possible. C'est une bonne chose d'identifier rapidement ses erreurs.
N'oubliez pas non plus d'écouter vos utilisateurs
Comme mentionné ci-dessus, il est toujours bon de disposer des données requises. Toutefois, se baser entièrement sur les données vous empêche d'analyser l'expérience globale que vous créez pour vos utilisateurs. Dépendre entièrement des données peut également s'avérer handicapant lorsqu'il faut prendre des décisions et que vous ne disposez pas de toutes les données nécessaires.
L'analyse produit expose de manière brute la manière dont le produit (ou une fonctionnalité spécifique) est utilisé, mais elle peut s'avérer très unidimensionnelle. Combiner ce que vous pensez savoir des données d'analyse produit avec le feedback qualitatif obtenu lors d'entretiens avec les clients, d'ateliers de tests de concepts et de séances d'entraînement vous offrira une meilleure visibilité afin de créer le meilleur produit possible.
