Julien Fournier - Tech Lead & Coordinateur d'agence
Découvrez notre calendrier de l'Avent spécial éco-conception
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.
Title document
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.
Dernièrement j’ai eu l’occasion d’accompagner un client dans la refonte d’un produit existant. Ce produit existe mais il est très loin des standards d’usage du marché (UX/UI pas bon), les utilisateurs n’en sont pas vraiment satisfaits (NPS pas bon), il a accumulé une dette technique abyssale (performance, fiabilité, disponibilité pas bonnes), l’organisation du delivery est “produit” mais le silo entre le business, le métier, l’IT reste total (dilution des responsabilités, incompréhension…) et l’approche n’est pas très user-centric…
Mais ce produit, il tourne, il fait même plusieurs millions d’euros de CA par mois (quand on a pas trop le choix on s’habitue même au pire).
Le brief du responsable digital était le suivant “je veux rapidement que notre expérience produit soit à la hauteur de ce que proposent les start up actuelles”. Défifoo !
Par où commencer ? cette question je me la suis posée, et reposée 1000 fois.
J’ai commencé par prendre en main le produit en mode utilisateur, et me faire ma propre idée. Ensuite, j’ai absorbé tous les avis clients que j’ai catégorisés et analysés, j’ai interviewé les membres de l’équipe client pour recueillir leur vision du produit actuel et leurs ambitions pour demain, j’ai lancé un questionnaire quanti auprès des utilisateurs et j’ai réalisé une bonne vingtaine d’interviews quali auprès de clients ou non pour récupérer leurs impressions sur l’existant, leurs principales frustrations et leurs principales attentes. J’ai analysé les data analytics, j’ai récupéré des grosses patates, mais quand il a fallu creuser dans le détail c’était impossible (le tracking n’avait pas résisté à l’épreuve du temps et des nombreuses releases).
Effectivement ça se confirmait, il y avait du boulot. En gros, il fallait tout revoir.
Avant d’entreprendre quoique ce soit, je me retourne vers le responsable digital et je lui communique la synthèse de mes investigations, il n’est pas surpris (CQFD).
Il comprend rapidement que l’on va devoir retravailler beaucoup de choses et que les impacts seront à la fois UX/UI, techniques, contenus, organisationnels… En résumé, il faut reposer des fondations solides au produit, repartir de la base.
Risky Business.
Sa réaction fut celle-ci “écoute je comprends, mais on doit avancer on n’a pas le choix, par contre on doit maintenir le business à flot, je n’accepterai pas de perdre du CA avec la nouvelle version.”
Ok, bon maintenant il faut s’organiser.
Le produit actuel est une constellation de parcours / fonctionnalités qui ont des niveaux d'intérêts / d'utilisabilité / de finitions à géométrie variable.
En gros on fait le ménage, on garde l’essentiel, on redéfinit les parcours de demain et on les design. On s’assure en parallèle que ce que l’on design puisse être mis en application sur le plan technique, contenu, opérationnel.
On se rend vite compte de nos excès : trop de choses à changer trop régulièrement, des contenus top mais que l’on n’aura jamais les moyens de produire, des informations importantes mais qui ne sont présentes dans aucun référentiel de données, des règles de gestion impossibles à mettre en œuvre...
Bref on doit encore frugaliser. Mais on garde les bonnes idées sur notre Jira Product Discovery, ca servira plus tard 🙂
On arrive à un résultat satisfaisant, le produit a minci, mais la base est là.
Deuxième RDV sponsor + comex, on leur présente le prototype MVP et on s’en prend plein la tête.
“Mais où est passée cette fonctionnalité, comment je communique sur ci et ça, comment le client peut consulter son…? Il y a rien dans ce que vous nous montrez !”
On sort les chiffres, on démontre le peu d’utilité de ce qu’on a enlevé, mais on rame. Clairement, le concept de MVP n’est pas compris… Et toujours la même hantise,” est-ce qu’on ne risque pas de perdre tout le monde en route et donc d’impacter notre CA ?!”.
Pas d’objection sur ce point, rien n’est garanti…
On leur propose de prototyper, tester auprès d’utilisateurs et on verra ce que ça donne. Go !
On prototype et on lance les tests (20 qualis), clients, prospects, différentes générations, urbain vs. non urbain… On récolte pas mal de feedback, mais aussi on comprend une chose, changer ses habitudes même pour le mieux, n’est pas évident.
Note pour plus tard, bien penser le déploiement, très bien le penser même car sinon ça risque de piquer fort.
Rebelote, RDV sponsor + comex, on présente les retours et leur application. On présente aussi le plan de mobilisation (aussi appelé la douloureuse : charge, impact SI, tooling, planning…) et on se prend toujours la même remarque -> est-ce que l’on a la garantie que l’on ne perdra pas d’argent avec cette nouvelle version ?
On leur expose un plan pour limiter le risque. Mais, on en reparlera plus tard dans la partie sur le process de déploiement.
Maintenant il faut délivrer, on propose de faire évoluer l’organisation actuelle pour réaliser la nouvelle version du MVP. On nomme un Product Manager, en charge de la strat produit (pare feu sponsor + Comex), un Product Owner en charge du delivery MVP, un lead tech + une équipe tech, un solution architect (pour identifier les services tiers à injecter), un Lead QA pour la partie test, un Product Designer et un DevOps pour fiabiliser.
On choisit les bonnes stacks, celles qui ont une garantie de pérennité dans le temps. Ça serait bête d’être dépassé dans 5 ans, et d’avoir du mal à maintenir et recruter des talents.
On découpe la réal en gros EPIC, à chaque delivery d’EPIC on décide de tester le rendu auprès de 10 utilisateurs (opération dérisquage numéro 2). Le mode pare feu du Product Manager est enclenché, il doit en dire assez sans rien promettre. On a un scope on s’y tient, le seul juge de paix est l’utilisateur.
C’est parti pour X sprints de 2 semaines.
3 Hypothèses possible :
1/ On joue au chamboule tout et on déploie d’un coup la nouvelle expérience : failed
2/ On découpe le déploiement par gros EPIC, et on aura une cohabitation old / new pendant un (long) temps : failed
3/ On prend une audience précise, on lui pousse la nouvelle expérience et on analyse, si c’est concluant on élargit : go !
Comment on organise le déploiement ?
1/ On prévoit un onboarding didactique où on explique le pourquoi du changement, et on présente les changements. Objectif ? prendre ses marques dans cette nouvelle expérience produit.
2/ On ajoute un bouton “retour à l’ancienne version” -> On suivra le KPI et on ajoute un formulaire pour comprendre pourquoi les gens veulent revenir à l’ancienne version (on en rappellera certains pour creuser).
3/ On ajoute un formulaire pour recueillir des enseignements : après la première visite, après la première action, après la première semaine, après le premier mois.
4/ On enregistre les sessions, on track les parcours clés, on analyse les chiffres et le cas échéant on dépiaute les vidéos de sessions.
5/ On ajoute un chat pour discuter en direct (on y a pensé, mais opérationnellement on a personne d’astreinte 7/7j et 24/24h et on ne croit pas aux robots multi-cuiseurs). On privilégie un numéro de téléphone visible au cas où -> On suivra le taux et les raisons d’appels.
On présente le plan au Sponsor / Comex, on parle d’un coup d’essai à impact de CA de 100 000 euros de revenus mensuels sur cette audience. Ça reste beaucoup, mais ça se tente.
On a le go, même si on sent que certaines personnes ne comprennent pas encore cette version frugale qu’on va livrer… Ils s’habitueront (ou pas).
On monitore tout, taux de disponibilité, taux de création de comptes, taux de conversion, numéro vert, formulaire…
Bilan des premières semaines, ça marche (on ne perd rien, on ne gagne rien) même si le taux de “retour à l’ancienne version” est de 20 % -> Faudra creuser en entretien 1:1 sur un panel et surtout continuer à accompagner le changement.
Alors oui on ne gagne rien (enfin le NPS augmente), mais on ne perd rien. Le CA reste identique, mais la performance est meilleure et vu le nombre de features dédiées à l’augmentation de CA qu’on a enlevées, on se dit qu’on a de la marge pour progresser.
Maintenant step 2, continuer le déploiement et surtout faire évoluer le produit sainement dans un environnement où tout le monde a 4 idées par jour 🔫. Défifoo, le retour.
La suite au prochain numéro.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
