Le feedback à tous les niveaux de la construction du produit
Dans cet article, je vais partager avec vous notre retour d’expérience sur ce que nous avons vécu et mis en place à Wiidii pour piloter notre activité Produit et Engineering.
C’est en prod, et après ?
Nous y voilà, vous avez construit la meilleure solution technique et tout est déployé en production. Vous avez fait ça bien, il y a une belle architecture distribuée, des microservices, tout un outillage CI/CD, des tests unitaires … Vous êtes confiants, et prêts pour continuer à délivrer de la valeur.
On le pensait aussi à ce moment là … et pourtant on ne savait pas dire si ce qu’on livrait était fonctionnel, performant, utilisé, ou tout simplement répondait au besoin. Ce qu’il nous manquait c’était le feedback.
Le feedback et la mesure
Le feedback se collecte à différentes étapes, non exclusives, de la construction d’un produit, on parle de boucle de rétroaction, ou feedback loop en développement agile. Sans aller jusqu’à vous détailler cette notion, je vous invite à aller voir cet article qui présente différents moments où il est possible de collecter du feedback. Il nous en manquait principalement deux : le monitoring technique de notre solution en production, et le suivi de l’utilisation du produit.
Monitoring applicatif
Architecture et complexité distribuée
Pour les équipes techniques, ces mesures et ce feedback en production prend la forme d’une plateforme de monitoring de l’infrastructure et des applications. Mais voilà, dans une architecture distribuée comprenant 80+ containers en live, avec des technos et langages divers (Python, C#), un bus de messages et des microservices qui discutent entre eux, le sujet n’est pas simple. Il n’y a qu’à voir la longueur de certains articles à ce sujet. Le choix initial s’était porté sur le célèbre combo EFK (Elasticsearch + Fluent + Kibana) pour le monitoring applicatif, complété par Grafana/Prometheus pour l’infra. Ces outils sont reconnus et largement exploités, il n’y a aucun doute sur leur capacité à répondre à ce besoin. La vraie question qu’on aurait due se poser était plutôt est-on en capacité de les mettre en œuvre ? ou encore l’effort qu’on va y mettre est-il justifié pour la valeur qu’ils vont nous apporter ? et donc est-ce le bon choix pour nous ?
Clairement, l’expérience nous a montré que non, après plusieurs semaines (=mois) d’effort de déploiement, de configuration, d’indexation, nous n’avions toujours pas le monitoring nécessaire pour bien mesurer et analyser notre environnement de production.
Le coût pas si caché de l’auto hébergement versus le coût visible du SaaS
On peut avoir peur des coûts pratiqués par les solutions clé-en-main proposées en mode SaaS, car ils sont souvent bien visibles et le calcul est rapide : nombre d’utilisateurs, nombre de hosts, nombre de lignes de logs. Pourtant, il ne faut pas omettre le coût de le faire soi-même. La solution choisie était open source, auto hébergeable (self-hosted), “gratuite” en apparence, et cela paraissait évident. Mais nous payions un prestataire pour la mettre en place…
Le calcul a été rapide pour comparer avec des offres SaaS : 1 jour de prestataire = 1 mois d’un service SaaS. Et même, en regardant l’effort déjà passé, cela payait le service sur l’année.
Attention à ne pas généraliser le propos, ni le calcul. Ce qui s’applique ici à notre usage, nos volumétries, ne s’applique pas forcément aux vôtres.
Pour les plus curieux, nous avons opté pour la solution proposée par DataDog, initialement pour leur offre Infrastructure et Log Management. Nous avons depuis rajouté l’APM pour la mesure de performance.
Avant de jeter notre dévolu sur cette plateforme, nous avions invité lors d’un Brown Bag Lunch leur “meilleur commercial régional”, Pierre Baillet, qui est SRE chez DataDog. L’occasion de voir les éléments techniques avant les aspects commerciaux. Nous avons bien évidemment poursuivi par une période d’essai pour valider à la fois la pertinence de la plateforme, la facilité d’implémentation et les hypothèses de coût/de volume.
Mesurer l’utilisateur
Savoir et comprendre ce que vous lui apportez pour savoir ce qu’il faut mesurer
A Wiidii, nous proposons un service par l’intermédiaire du produit que nous distribuons à nos clients et utilisateurs. Le produit est donc un moyen d’accéder à ce service, mais la principale valeur ajoutée que nous apportons (à nos utilisateurs) est ce service.
Ce service est un assistant (personnel du quotidien), qui prend le relai sur les choses que vous avez (ou auriez) à faire, mais que vous n’avez pas envie, pas le temps, pas les capacités de faire. Il est là pour vous faciliter la vie, pour peu que vous lui demandiez, et c’est là tout notre enjeu.
Ce que les utilisateurs découvrent en premier ce n’est pas le service, mais le produit qu’ils ont entre les mains. Un des principaux enjeu du travail de notre produit est donc d’accompagner l’utilisateur à comprendre, le plus rapidement possible, cette valeur qu’on peut lui apporter.
La difficulté est que cette valeur n’apparait qu’à l’usage, et le parcours de l’utilisateur jusqu’à l’étape ultime où il va découvrir et comprendre cette valeur est au cœur des sujets que nous travaillons sur le produit.
Le moyen est-il efficace ?
Si j’ai soigneusement évité de vous détailler la forme du produit, c’est pour vous permettre de bien comprendre le double enjeu service/produit peu importe la forme que prend ce dernier. Il s’agit en fait d’une application mobile (iOS et Android) de gestion et d’organisation du quotidien dans laquelle notre service d’assistant y est embarqué.
Ce produit est un moyen pour nous d’apporter notre service à l’utilisateur, ce que nous devons mesurer donc, c’est son efficacité à le faire. Nous avons récemment travaillé sur 2 thèmes :
- la compréhension du produit
- la rétention
Pour comprendre et découvrir rapidement l’intérêt du produit, nous avons travaillé sur le parcours d’arrivée dans l’application, l’onboarding, de l’inscription dans l’application (création de compte), à la découverte et aux premières interactions.
Pour pérenniser cela, il nous fallait aussi travailler la rétention de nos utilisateurs, qui est comme pour tous les développeurs d’application mobile un sujet récurrent.
Pour aborder ces sujets, nous avons du faire des hypothèses, des tests, mais cela n’aurait servi à rien si nous n’avions pas de quoi mesurer les résultats obtenus.
User Story, valeur estimée et feedback
La méthode que nous avons choisie pour décrire et définir le travail à réaliser sur le produit est la rédaction d’User Story (ou Récit Utilisateur). Outre la description du besoin, associées au framework SCRUM, ces user stories permettent de porter d’autres éléments :
- quelle est la valeur estimée qu’une User Story va apporter (à l’utilisateur),
- quel est l’effort pour la réaliser.
Une des premières stratégies, couramment appliquée, est de prioriser en fonction du ratio valeur/effort. Cela donne bien un plan de travail ordonné et cohérent, mais il ne permet pas de valider les hypothèses faites, et notamment la pertinence de la solution apportée.
Pour cela, il y a des stratégies complémentaires à appliquer, comme définir et positionner des indicateurs (KPIs). En pratique, positionner un indicateur n’est pas toujours applicable au niveau de détail d’une User Story. En effet, l’indicateur est parfois plus global, il peut être au niveau d’une fonctionnalité ou d’une équipe. Par exemple chez ManoMano, l’organisation produit comporte des “Tribes”, chacune avec son propre lot de KPIs qu’elle va chercher à maximiser.
Avant d’en arriver là, et comme peuvent le faire certaines équipes chez Microsoft, nous avons opté pour intégrer dans notre Definition Of Done une collecte de feedback, une prise de mesure, quand cela est possible. Par ce moyen, nous pouvons valider (ou non) l’hypothèse faite et ajuster en fonction notre plan de travail.
Mesurer l’usage factuel d’une fonctionnalité
Ah si seulement je pouvais partager vos suggestions avec ma femme pour organiser nos vacances, ça serait top !
On pourrait même rajouter
Je suis sûr que ça va intéresser du monde !
C’est en tout cas l’hypothèse qu’on a faite en développant au sein de notre application cette fonctionnalité. Pour valider cela, nous avons rajouté un “event Amplitude”, donc la mesure factuelle de l’usage de la fonctionnalité.
Comme son nom l’indique nous avons opté pour l’offre Amplitude Analytics, qui est une plateforme SaaS de collecte et d’analyse des utilisateurs.
Les avantages de cette plateforme sont multiples :
- rapidité de mise en place : pas de déploiements (car dispo en SaaS) et intégration facilitée via un SDKs pour les principales plateformes,
- documentation simple et claire,
- l’offre gratuite est largement suffisante (pour nos usages encore une fois),
- capacité d’analyse poussée via une interface intuitive : les équipes produits sont autonomes pour construire les analyses.
Pour en revenir sur l’arrivée au sein de l’application et la compréhension de la valeur ajoutée du service, nous avons rajouté des écrans permettant à l’utilisateur de nous indiquer des préférences ou habitudes qu’il pourrait avoir afin de lui proposer dès l’arrivée dans l’application des suggestions de cas d’usage qui lui parlent. Amplitude, nous a permis de valider le fait que rajouter des étapes supplémentaires à ce moment ne nous faisait pas perdre des utilisateurs. En effet, le ratio entre la première étape et la dernière reste le même malgré l’ajout de 3 étapes, et donc 3 écrans complémentaires.
Collecter le feedback utilisateur
Une partie de notre offre étant proposée en B2B2C, nous n’avons pas un contact direct avec tous nos utilisateurs.
Cela n’empêche pas de pouvoir aller chercher du feedback, le sujet a d’ailleurs été abordé lors d’un session de La Product Conf : Comment récolter des feedbacks user dans un contexte B2B ? par Maia Metz.
Nous avons ainsi intégré, dès que cela est impossible, la présence d’un product owner dans les contacts commerciaux, tests, ou stratégiques que nous avons.
En complément, nous proposons directement au sein de notre application, la possibilité de soumettre un feedback une fois le traitement terminé et donc le service rendu, via un système de notation.
Très rapidement, justement car ce feedback sur ce système nous a été remonté, nous avons rajouté un niveau de précision supplémentaire pour expliquer les raisons de la notation, en portant une grande attention sur le choix des bulles et leur nombre, afin de ne pas demander un effort trop important à l’utilisateur. Nous lui laissons toutefois un champ libre, pour ceux souhaitant s’exprimer plus longuement. Tout ceci est bien évidemment optionnel.
Cette mesure nous permet d’en apprendre plus sur le ressenti de nos utilisateurs quant à notre service, et axer à la fois nos efforts sur le produit, mais aussi sur la communication.
Analyser nos données transactionnelles
Comme tout produit hébergé, et toute plateforme de service, nous traitons un certain volume de données, et ce, du fait même de notre activité. Nous ne faisons pas d’autre usage de ces données que pour apporter le service à nos utilisateurs.
Ainsi, pendant longtemps leur usage était majoritairement transactionnel, comprendre pour la finalité d’un traitement particulier (par exemple “Savoir que l’utilisateur est vegan pour choisir un restaurant adapté”). Une fois le service rendu, la donnée n’est plus exploitée. Nous avons donc cherché à les valoriser, pour comprendre nos utilisateurs, les usages, piloter à la fois notre activité et le produit, et ainsi pouvoir impacter les décisions futures.
Sans tout détailler, je vais juste vous dire que nous avons choisi la plateforme Databricks, entre autre, car elle est intégrée en version entièrement managée dans des offres cloud comme celle de Microsoft Azure. Aussi, nous avons pu nous le permettre, car nous bénéficions du programme d’accompagnement pour Startup de Microsoft et que nous avions déjà une équipe toute à fait compétente pour savoir l’exploiter.
A ce jour, nous avons une plateforme de données digne des plus grands, mais surtout l’ensemble de la société est aujourd’hui capable d’ouvrir un rapport PowerBI pour suivre l’activité, et analyser, voire impacter sa propre activité.
Je ne vais pas plus détailler notre implémentation, mais vais plutôt vous renvoyer vers l’article de Sylvain qui détaille notre “Stack Data”. Enfin, pour des compléments techniques, je vous invite à aller voir le blog de Paul PETON.
Du côté de l’impact sur notre activité, cela a été extrêmement important. En effet, en analysant l’usage qui était fait de notre plateforme, nous avons pu détecter des utilisateurs “atypiques” qui sortaient du lot. Ils étaient plus actifs, et pas spécifiquement sur certains usages, mais en général pour tout. En d’autres termes, leur taux de rétention que nous cherchions à impacter était très supérieur. En allant creuser cet “insight”, nous avons pu entrer en contact avec ces utilisateurs, et avons alors découvert l’importance voire la nécessité que représentait notre proposition pour une population utilisateur que nous ne ciblions pas spécifiquement.
Ceci nous a conduit à créer une nouvelle offre complète, dédiée spécifiquement pour ces utilisateurs : OneCompagnon.
Moins impactant, mais tout aussi intéressant, en travaillant l’arrivée dans notre application, nous avons rajouté une question sur les animaux de compagnie, en faisant l’hypothèse d’un cas d’usage qui pourrait intéresser nos utilisateurs.
Notre plateforme d’analyse des données nous permet de suivre les données renseignées et l’impact de l’ajout de cette fonctionnalité sur ce que les utilisateurs font du produit
Ce n’est pas fini…
Maintenant que nous avons tout ce feedback, il nous faut passer à l’étape suivante : organiser, trier, et suivre efficacement tous ces éléments collectés, afin de continuer à bien mettre en œuvre les actions adéquates sur le produit et plus généralement notre organisation.
Il nous reste aussi des canaux de remontée de feedback utilisateur qu’il nous faut agréger et consolider avec les autres, comme les divers retours faits par des utilisateurs que nous pouvons avoir en direct. Il peut s’agir d’un retour lors d’un contact commercial, ou stratégique, comme de retours d’utilisateurs que notre Customer Success Manager (🥰Fabien) prend lors de campagne de test, voire tout simplement de nous mêmes, puisque nous sommes utilisateurs de notre propre produit.
Du côté de notre plateforme de données, l’étape suivante est logiquement d’aller vers encore plus d’automatisation, via du Machine Learning, ce que nous permettra de faire sans difficulté Databricks.
