Si plusieurs méthodes existent pour faire le tri parmi les besoins fonctionnels, seul le modèle de Kano tient compte de la satisfaction client. Comment en tirer ? Réponse, exemple à l’appui.
Sur le podium des buzzwords, l’agilité se partage la première marche avec la « transformation digitale ». Et pour cause : l’impératif de réduction du « time-to-market » appelle une gestion de projet rapide et efficace, agile donc. Pour y parvenir, encore faut-il savoir trier et prioriser les besoins fonctionnels. Pas si simple : entre la crainte de voir un concurrent débarquer à tout moment et celle de voir son service boudé par les utilisateurs, la tentation est grande de courir après plusieurs lièvres à la fois.
Pour limiter ces risques, plusieurs solutions sont à disposition :
La Méthode de Moscow : Elle propose de noter les priorités du backlog en faisant intervenir les parties prenantes mais sans stratégie de satisfaction client. Pour plus d’information, allez voir: PRIORISER, MÉTHODE 1 : MOSCOW
La Story map : Avec elle, les fonctionnalités sont classées selon deux axes : le parcours utilisateur sur l’axe horizontal et la priorité des User Stories sur l’axe vertical. Ici encore, aucun lien n’est établi avec des critères de satisfaction client.
Le Modèle de Kano : Comme son nom le laisse entendre, il s’appuie sur le diagramme de Kano qui a pour finalité d’évaluer la satisfaction client. Cet outil a été inventé par le Dr Noriaki Kano en 1984. Conférencier, écrivain et surtout consultant dans le domaine du management de la qualité, au Japon. Il est actuellement professeur émérite de l’Université des sciences de Tokyo.
Si ces 3 solutions permettent une priorisation, une seule – celle qui s’appuie sur le modèle de Kano – tient donc compte de la satisfaction client
Dissocier satisfaction et non-satisfaction
L’objectif du modèle est de prendre en compte les retours des utilisateurs du produit et/ou du service pour modéliser la satisfaction client sur un diagramme. L’approche réside dans la dissociation de la satisfaction et de la non-satisfaction au regard de la présence ou pas de la fonctionnalité attendue par le client. La satisfaction client est une clé majeure aujourd’hui, qui rend le client fidèle et est donc un pilier de rentabilité important. Le modèle de Kano présente l’intérêt de se décliner sur les différentes phases.
Pré-développement : L’équipe marketing peut utiliser ce modèle pour cibler le marché commercial et analyser les chances de réussite du produit – plus la satisfaction client est élevée plus les chances de réussite sont grandes. Le modèle permettrait de faire apparaître les caractéristiques fortes dans une perspective de succès du produit.
En cours de développement : le responsable projet, le Product Owner dans le cas d’un projet en méthode Agile, manage la priorisation des fonctionnalités livrées en se basant sur la satisfaction client. Ce qui permet de livrer, dans le cas de sprint, les fonctionnalités de la plus haute valeur business dès que possible.
En post-production : des évolutions pourraient être valorisées (ou non) par ce modèle. Une étude de marché pourra aussi utiliser ce modèle pour assurer la pérennité du produit.
Concrètement voici le diagramme qui porte le modèle de Kano :
Pour construire le modèle, un questionnaire recueille, pour chaque fonctionnalité, le niveau de satisfaction de l’interviewé. La méthode consiste à évaluer successivement la satisfaction en présence et en l’absence de la fonction. Mais le modèle va bien plus loin en modélisant 3 groupes principaux sur la courbe de Kano :
Les attentes de base : généralement non exprimées, elles représentent les attentes que les fournisseurs doivent impérativement satisfaire pour rester sur le marché. Priorité Haute.
Les attentes proportionnelles : la satisfaction augmente avec le niveau de performance délivré par la fonction. Priorité Basse.
Les attentes attractives : le fournisseur surprend son client avec une fonctionnalité à valeur ajoutée qu’il n’attendait pas. Les fonctions vont au-delà des attentes client. Un terrain propice à l’innovation. Néanmoins leur absence se solde par une frustration client. Priorité Moyenne.
Les bénéfices du modèle de Kano dans la pratique
Dans la pratique, la méthode de Kano apporte donc plusieurs atouts :
Elle contribue à évaluer les attentes des clients grâce au niveau de satisfaction associé.
Elle suscite une rencontre avec les clients pour les écouter et améliorer ainsi la compréhension des attentes
Elle aide à trier et prioriser les fonctionnalités à développer
Elle facilite l’évaluation des produits innovants.
Elle augmente la fidélité des clients, un client non satisfait cherchera tôt ou tard le même service chez la concurrence. L’objectif est de la satisfaire avant qu’il parte.
Un impératif : bien structurer les questionnaires
Pour l’exécuter, il est capital de bien mener les questionnaires. Voici un exemple – avec des réponses arbitraires à des fins d’illustration.
Si votre téléphone portable possède les apps des réseaux sociaux dès son premier démarrage (Facebook, Twitter, LinkedIn, …) : a. cela vous plait beaucoup b. cela vous intéresse c. vous trouvez ça normal d. vous vous en contentez e. cela vous déplaît
Si votre téléphone permet de joindre vos amis en faisant un appel téléphonique classique a. cela vous plait beaucoup b. cela vous intéresse c. vous trouvez ça normal d. vous vous en contentez e. cela vous déplaît
Si votre téléphone n’a que 5 sonneries différentes (cela est transformé en une fonctionnalité manquante, telle que « choix de 50 sonneries » ) a. cela vous plait beaucoup b. cela vous intéresse c. vous trouvez ça normal d. vous vous en contentez e. cela vous déplaît
Si votre téléphone présente un écran 4k a. cela vous plait beaucoup b. cela vous intéresse c. vous trouvez ça normal d. vous vous en contentez e. cela vous déplaît
En appliquant ici le modèle de Kano, nous obtenons donc les catégories de priorités suivantes :
Fonctionnalité « réseaux sociaux » : elle figure dans le groupe rouge et fait donc partie des attentes attractives : c’est une priorité moyenne, cette fonctionnalité devrait être présente.
Fonctionnalité « pouvoir joindre ses amis » : dans le groupe vert, elle représente une attente de base et une priorité haute.
Fonctionnalité « peu de sonneries » : sans incidence réelle car attente proportionnelle, sûrement une fonctionnalité à améliorer dans le futur, priorité basse.
Fonctionnalité « écran 4k » : de même, cependant la décision de l’inclure ou pas dépend aussi du coût associé. Il faudrait étudier les risques de cet investissement. Priorité basse.
Récapitulatif des fonctionnalités priorisées :
Pouvoir joindre ses amis
priorité haute
Applications “réseaux sociaux” déjà installées
priorité moyenne
5 sonneries disponibles
priorité basse
écran 4k
priorité basse
Inspiré ? A vous d’appliquer le modèle de Kano sur vos propres projets.
Rupture douce 05 : les individus et les interactions d’abord !!
Rupture douce 05 : les individus et les interactions d'abord !!
Les individus et les interactions d’abord !!
Les Individus et les interactions d’abord !! Le nouveau Tome de Rupture Douce est disponible !!! 40 textes, 30+ auteurs, de nombreuses illustrations pour remettre les pendules à l’heure en matière d’agilité et de transformations agiles.
Auto-édition sur lulu.com, 15€ HT (coût de fabrication 10€ + 5€ qui seront reversés aux resto du coeur. Pour mémoire 536€ = repas pour une famille de 4 pour tout l’hiver.
Quel plaisir pour moi d’avoir fait partie de cette aventure collective, capable d’accoucher d’un livre en quelques semaines. J’ai immédiatement plongé dans le projet avec quelques pages qui proposent ma vision d’une agilité agnostique des frameworks, mais centrée sur l’humain, le (bon) sens et la recherche de simplicité. Et ça aussi, ça fonctionne « à l’échelle ».
Séverin Legras
4ème de couverture
Durant toutes ces années, l’agilité a connu de beaux succès, et encore trop d’échecs. Dans tant d’endroits, les transformations agiles sont encore asservies par une descente de processus agiles (Scrum, Kanban, Safe, etc) sur les individus. Heureusement, nous pouvons savourer des initiatives comme Agnostic Agile ou bien Heart of Agile, cultivées par des anciens de l’agilité, ceux qui ont donné naissance au Manifeste Agile en 2001.
Ce tome 05 s’inscrit dans cette mouvance : ici, les contributeurs entendent rappeler que notre manifeste précisait dès sa première valeur « les individus et les interactions plus que les processus et les outils ». Vues les confusions constatées, autant simplifier en « les individus et les interactions d’abord !! ».
Dans vos mains, vous tenez une nouvelle collection d’histoires épatantes, pour remettre les pendules à l’heure. Retours d’expériences authentiques, approches pragmatiques : vous disposerez d’un beau matériel pour espérer que les 10 prochaines années soient encore meilleures.
Avec Rhapsodies Conseil, l’intelligence collective devient une évidence…
Favoriser la créativité des individus et du collectif en faisant émerger des comportements et des pratiques bienveillantes, c’est la mission que s’est fixé le cabinet Rhapsodies Conseil pour aider les entreprises à évoluer vers l’intelligence collective.
Le management directif, autocratique et hiérarchisé, symbole d’une organisation pyramidale a-t-il fait son temps ?
Pour Rhapsodies Conseil, cabinet indépendant de conseil en management, c’est une évidence !
Claranet | Oxalide et Rhapsodies Conseil vous invitent à découvrir un retour d’expérience de transformation vers une Organisation plus Agile.
Co-construit en intelligence collective, ce modèle aligné sur la stratégie de développement prévue par Oxalide (groupe Claranet) visait à faire face à des enjeux de croissance, d’organisation, de scalabilité dans un marché ou le time-to-market est le nerf de la guerre.
La conception d’un modèle de transformation en mode agile différenciant, intégrant leur cible, leur rythme et une trajectoire adaptée, était majeure pour atteindre les résultats souhaités.
Une Organisation Produit conçue avec les équipes et les consultants de Rhapsodies Conseil qui ont eu plaisir à mener cette mission.
Coach Professionnelle, Team Leader Transformation Agile des Organisations
Comment découper les besoins au sein d’une vaste organisation de 5000 collaborateurs pour mieux échanger et créer de la valeur ?
C’est l’une des questions en filigrane de l’accompagnement que nous menons en tant que coach agiles auprès des équipes produits de vente-privée depuis 1 an. Une question posée dans le sillage d’une transformation qui voit le leader de la vente flash en Europe passer d’une organisation par technologies à une organisation par produits.
Pour comprendre l’importance de ce découpage, prenez le temps d’imaginer un gros burger composé de nombreuses couches d’ingrédients. Vous avez deux manières de vous y attaquer. La première consiste à manger chaque couche, l’une après l’autre. Autant dire que vous ne profiterez pas du vrai goût du burger. Ou bien vous pouvez croquer dans ce burger à pleines dents. Vous aurez alors en une bouchée un peu de de chaque ingrédient, ce qui vous donnera une bien meilleure appréciation de ce qu’est véritablement un burger. Et comment l’améliorer à l’avenir.
Dans une organisation, le découpage des besoins, pour rester aligné sur la création de valeur, obéit à la même logique. Encore faut-il transcrire ce principe dans la pratique. Comment les équipes de vente-privee y sont-elles parvenues ? Avec quels enseignements ? Ce sont les intéressés qui en parlent le mieux.
Chez Vente-privée, à quels signes voyons-nous qu’une équipe livre de la valeur de manière optimale ?
Quand l’équipe recourt à des pratiques qui améliorent sa connaissance produit Identifier, anticiper et réduire les risques suppose de bien connaître son produit. Ces risques ont des origines multiples : adhérences externes, complexité technique ou fonctionnelle, compétences de l’équipe, interdépendances avec les autres équipes produits et transverses… Voilà pourquoi la collaboration doit être continue.
Connaître son produit
« L’architecture micro-service que nous mettons en place peut rendre une plateforme difficile à appréhender d’un point de vue fonctionnel. Mais avec la mise en place des “3 Amigos” nous avons développé les connaissances fonctionnelles de l’équipe produit. Résultat, nous délimitons mieux les périmètres de nos composants (acquisition d’image, stockage, publication…) ce qui améliore le delivery ainsi que la qualité des nouvelles features. Au final, c’est toute l’architecture qui est mieux exploitée. »
Vincent Oostenbroek de Lange – Lead Developper du Produit Media Prod
Les “3 AMIGOS” ? Concrètement, il s’agit d’un moment d’échange entre le PO/Business analyste, le testeur et le développeur pressenti pour coder. Les participants posent des questions pour clarifier les besoins et identifier les risques. Une bonne manière de couvrir les angles morts de chaque rôle. Suivant la maturité de l’équipe produit, c’est le moment où les critères d’acceptance sont décrits.
Chez Vente-privée, à quels signes voyons-nous que les équipes développent leur connaissance du produit ?
Quand l’équipe échange en continu L’équipe discute les besoins avant qu’ils n’arrivent dans le backlog des développeurs. Pour certaines équipes produit de vente-privee, nous avons donc amélioré la phase entre le moment où les clients émettent les besoins et le moment où ils arrivent dans le backlog des développeurs. Chaque équipe produit, suivant ses spécificités, a choisi les pratiques qui conviennent le mieux à leur contexte. Sans surprise, l’atelier des “3 AMIGOS”*, gage de succès, s’est aussi imposé ici.
Échanger pour définir les critères d’acceptance
« En décrivant pour chaque user story les critères d’acceptance, nous réussissons à remplacer les exigences avec un langage clarifié en termes fonctionnels et techniques. Ainsi tous les cas de tests sont anticipés en amont, orientent les choix techniques et préviennent les risques de bugs en production. Cette façon de travailler réduit d’autant le temps de qualification puisque les cas complexes ou tordus sont largement anticipés durant la phase de conception. Ce travail collectif et collaboratif entre les QA, dev et PO offre à l’équipe produit Orderpipe un gain de temps dans la livraison en production des MVP. La prochaine étape pour nous est de rédiger les tests de manière automatisée.«
Hicham Sassi – QA du Produit Orderpipe
Chez Vente-privée, à quels signes voyons-nous que le découpage des besoins est entré dans les habitudes de travail ?
Quand l’équipe sait découper les besoins fonctionnels par la valeur L’équipe s’assure de livrer de la valeur à chaque itération. Cela commence par la priorisation du backlog par la valeur jusqu’au découpage vertical en mode MVP (Minimum Viable Product).
Prioriser par la valeur
« Il y a un adage qui dit « les intérêts des uns ne sont pas forcément ceux des autres« . Et cela s’applique très bien quand il s’agit d’un produit transverse à l’ensemble des autres produits. C’est le cas du produit Personnalisation : il offre un service qui diminue l’effort de recherche des ventes disponibles pour les membres et permet aux équipes produits vente-privee de booster leur KPI (de générer plus de valeur sur leur propre produit).
Toutefois cette synergie accroit aussi la complexité. En effet, une fonctionnalité peut détruire de la valeur business pour un produit tout en générant sur un autre (i.e le voyage peut perdre au détriment du loisir). En conséquence, il est indispensable de bien découper les besoins fonctionnels afin de tracer à la fois le flux de valeur et la complexité technique. Cela permet à l’équipe produit Personnalisation de bien définir les MVP et maximiser la valeur délivrée pour l’ensemble des produits. »
Ivan VUKIC – Product Owner du Produit Personnalisation
L’équipe sait aussi s’arrêter quand elle ne produit plus de valeur.
Expérimenter par la valeur
« Dans le cadre de nos campagnes d’acquisition, nous nous étions donnés pour objectif de booster les téléchargements de l’application vente-privee sur les stores (iOS/Android). Nous sommes partis de l’hypothèse qu’une meilleure note sur ces stores améliorait le taux de téléchargement de l’app (nombre de téléchargements rapporté au nombre d’utilisateurs qui voient la description de l’app).
Pour éprouver cette hypothèse, nous avons sorti un 1er MVP de notre feature : le fait de pousser une interface de notation à certaines populations juste après un achat, ainsi le « user » est dans une dynamique positive avec le service vente-privee. Une fois ce module en production, et après analyse, nous nous sommes rendus compte que :
– nous améliorons la note de l’app (de 2.5 à 4.5 sur iOS par ex.)
– nous n’améliorons pas le taux de téléchargement de l’app
Nous avons mis de côté les évolutions possibles de ce module (optimisation de l’affichage, exécution d’autres scénarios…) puisque que nous n’incrémentions pas le nombre de nouveaux porteurs de l’app par rapport à la valeur attendue. »
Matthieu WILLAIME – Anciennement Product Owner du Produit User-Engagement, dorénavant PO Navigation
A quels signes voyons-nous que le découpage est efficace ?
Quand l’équipe sait découper les besoins fonctionnels en réduisant la complexité Objectif : limiter les inconnues afin que les développeurs, les testeurs, les UX-UI, les data analystes et les business analystes soient confiants en leur capacité de présenter ce qu’ils ont prévu de livrer lors du sprint planning. Une fois bien compris, un besoin fonctionnel ou “Business feature” est découpé en 1, 2 ou 10 users stories ou enablers (tâches techniques, UX…). Ce qui nous donne un bon hamburger :
Découpage d’un besoin fonctionnel en hamburger
Découper les besoins fonctionnels
« Depuis la mise en place de l’agilité dans notre équipe, nous rencontrions des problématiques concernant la taille des stories. Certaines s’apparentaient davantage à des business features et nécessitaient plusieurs sprints pour être réalisées. Avec le découpage en hamburger, nous nous posons les bonnes questions afin de découper au mieux les besoins. Le retour est très positif, nous parvenons mieux à nous projeter dans le temps, avec une réelle vision du travail à fournir et sur la façon de l’adresser. »
Grégory Beer – Scrum master du Produit Media Prod
Une façon de s’assurer du bon niveau de découpage du besoin fonctionnel consiste à estimer la complexité. L’équipe se pose des questions jusqu’à l’atteinte d’une complexité assez basse des users stories et enablers (exemple : en dessous de 5 sur l’échelle de Fibonacci) afin d’identifier les risques et les inconnues. C’est un des temps d’apprentissage sur l’équipe et le produit.
Exemple d’une échelle d’estimation de la complexité
S’affranchir de l’estimation grâce à la maturité de l’équipe
« Pour l’équipe Navigation, l’estimation a été un passage obligatoire et bénéfique dans notre maîtrise de l’agilité. Parfois, au début, la facilité nous poussait à mettre une estimation élevée sans remettre en question le découpage de la tâche. Après quelques mois où nous nous sommes imposés de découper les tâches pour être en dessous d’un niveau de complexité de 8, nous nous sommes rendus compte que notre découpage devenait optimal.
Nous avons choisi de nous passer des estimations en utilisant le nombre de tâches plutôt que le nombre de points de complexité comme mesure d’avancée de sprint. »
Paul-Emmanuel Garcia – Scrum master / développeur iOS Produit Navigation
Takeaways
Peu importe les rituels et les pratiques adoptés tant qu’ils contribuent à faciliter les échanges pour mieux découper les besoins.
Ces pratiques ne sont pas une fin en soi : elles contribuent seulement à acquérir des comportements agiles, aident les équipes à gagner en confiance, à travailler ensemble pour trouver des solutions – et non pour résoudre des problèmes.
L’histoire ne s’arrête pas une fois que l’équipe sait collaborer pour créer de la valeur : il faut encore apprendre à réfléchir et à s’améliorer pour de boucler les 4 étapes du cycle du cœur de l’agilité (collaborer – délivrer – réfléchir – améliorer).
avec la participation deSylvie Moumen Coachs agiles chez vente-privee, Coachs professionnelles systémiques & Coachs Process Com certifiées
Vous gérez un produit : apprenez à prioriser et à mesurer la valeur de votre produit !
Comment choisir entre développer un « bot de messagerie » sur votre application ou bien un nouvel onglet ? Peut-on mesurer en amont la valeur de ces fonctionnalités ? Quelles sont les approches pour calculer, voire traduire cette valeur en € ?
Voilà les problématiques auxquelles font face les Product owner pour qui les métriques sont devenues une obsession.
Nous allons aborder les concepts et les outils à maitriser pour y arriver, accrochez-vous, c’est parti !
Prioriser, méthode 1 : Moscow
Ci-dessus un exemple d’application de la méthode MOSCOW sur le sprint backlog d’un site de vente quelconque.
La première approche qui se veut pragmatique n’est jamais très loin de la méthode MoSCoW (Must have, Should have, Could Have et Won’t Have). On affecte un niveau de priorité aux « actifs / features / fonctionnalités* » que l’on veut intégrer au produit. Pour le faire bien, on essaie de le faire souvent, en travaillant uniquement ce qui est le plus prioritaire. * pour un produit qui n’est pas informatique ou qui comporte des contenus sans développements (vidéos, …), on pourra parler d’actif ou de feature
Par exemple, imaginons que vous ayez 3 mois pour développer un site de vente, comment s’y prendre ?
On liste l’ensemble des grandes fonctionnalités : accéder au catalogue de produits, visualiser l’historique des achats, acheter, etc …
On assigne une priorité à chacune
Les Must have : acheter, accéder au catalogue de produits
Nice to have : accéder à l’historique de ses achats…
Le planning reste clair : les « must have » seront développés en premier et les « nice to have » restants, etc … si jamais il nous reste du temps !
Prioriser, méthode 2 : orientée données
La seconde, orientée données, s’inscrit une démarche Lean Startup (Build, Measure, Learn).
Ci-dessus un exemple d’application orientée données sur le développement de facebook connect pour un site de vente quelconque.
Facebook Connect est un module social externe ousocial loginpermettant à un site web de proposer à ses visiteurs d’utiliser leur compte Facebook pour s’identifier sur le site visité. On fait des hypothèses basées sur notre compréhension du marché, on mesure notre adéquation et on apprend de ses choix. Pour le faire bien, on met en place des standards de calcul, on identifie au préalable les métriques à suivre pour un actif donné et on les suit. La dernière étape permet de savoir dans quelle mesure valider ou invalider ses choix. Dans notre exemple ici, on estime que la valeur (ou BV : « Business Value ») de développer Facebook Connect pour que nos visiteurs s’identifient sur notre site de vente est de 10 000€ par jour. Une fois la fonctionnalité priorisée/développée, on suit notamment le taux de conversion : pourquoi n’atteint-il pas les 20% d’augmentation estimés ? Le taux d’abandon en page d’identification a lui fortement diminué, le taux d’abandon sur une autre page a t il augmenté ? Où ? … A mi-chemin entre les 2 approches ? Toutes les méthodes de priorisation/mesure que l’on appellera « par scoring ».
Ce n’est pas indispensable d’être orienté données
Tout d’abord, la force de l’approche orientée données réside dans sa capacité à adresser des problématiques business globales et complexes. C’est donc dans ce type d’environnements (où la connaissance des usages est particulièrement importante) qu’elle prend tout son sens, ce n’est peut-être pas le cas de votre environnement… La deuxième variable est temporelle, il faut savoir qu’un produit suit un cycle de vie :
Tant qu’il n’a pas atteint sa forme minimale viable, ça n’a peu/pas de sens de chercher à valoriser les actifs qui le composent. Le MVP est par définition le premier ensemble qui constitue le produit que l’on peut valoriser et le produit finit sa vie lorsqu’on ne peut plus le valoriser.
Enfin la dernière composante est le rapport à la concurrence. « Combien va me rapporter tel service ? Telle feature ? Quel est la « business value » de passer maintenant sur telle technologie ? Ou au contraire, combien est ce que ça va me couter de ne pas faire cette migration pendant 1 an ? » Ce sont des questions qu’il est d’autant plus naturel de se poser que la capacité d’une entreprise à mettre sur le marché très rapidement un produit ou une nouvelle version est devenu un facteur concurrentiel à part entière. L’approche garantit des retours fréquents et qualitatifs permettant de s’adapter d’autant mieux dans ce type de contexte.
Quels sont les outils pour calculer la valeur d’une fonctionnalité de son produit ?
La valeur « business » représente ce que vaut une fonctionnalité ou un service en embrassant tous les aspects qui font sa force. Par défaut il ne faut pas perdre de vue qu’il y aura toujours certains aspects qui seront mal appréhendés par ces méthodes : comme la valeur qui est créée lorsque des utilisateurs interagissent avec notre contenu ou alors la « prime au premier » que l’on obtient à délivrer un service qui n’existait pas auparavant… L’important est donc de savoir que cette mesure ne se substitue pas à l’intuition et d’utiliser des métriques de calculs comparables pour chacun de vos actifs :
Pour une fonctionnalité ou un service qui est supposé générer des revenus ou une réduction de couts, c’est bien ce que l’on cherchera à estimer pour calculer un ROI (cf. 2nde image)
Idem pour un actif qui contribue à ce qu’un autre rapporte : si un actif ne peut fonctionner sans un autre, c’est que cet actif contribue à la valeur générée : Imaginons (si on reprend notre exemple) que le développement de FB Connect pour notre site de vente nécessite le développement d’une autre fonctionnalité ou d’un autre actif. On parlera alors d’un « enabler » et il s’agira d’estimer dans quelles proportions il contribue à notre hypothèse d’augmentation de BV portant sur l’augmentation de taux de conversion (et potentiellement à d’autres) pour en estimer la valeur.
Pour d’autres fonctionnalités, services ou contenus, liés à une échéance, comme une amende réglementaire (Hello GDPR) ou un spot publicitaire, on estimera à l’inverse ce que cela nous coute de ne pas faire, on appelle ça le cout du délai :
Exemple d’application du coût du délai sur 2 contenus comparables
Quantifier la valeur d’une feature n’a pas de sens si l’on ne suit pas les résultats …
L’AB Testing ou Split Testing est un bel exemple d’utilisation bout en bout de la donnée. Le procédé est notamment poussé par de nombreux designers pour affiner leurs choix et leur compréhension des usages. Il s’agit de tester plusieurs variantes d’un même élément directement face à des utilisateurs : les utilisateurs sont renvoyés aléatoirement vers chacune des variantes pendant un temps donné. On garde à la fin la meilleure variante : celle qui a les meilleurs taux de conversion, de transformation ou n’importe quelle métrique que vous voulez améliorer.
Exemple d’AB Testing sur une page web
A ce jeu, les principaux leaders sur des services numériques excellent (75 % des sites ayant un trafic supérieur à 1 million de visiteurs font de l’A/B Testing). Au-delà d’optimiser la décision, le procédé permet d’en apprendre plus sur ses visiteurs et ce qui fonctionne, d’en connaitre finalement plus sur la « capitalisation » vue de l’utilisateur de son produit. Même si l’on n’est pas dans une logique d’AB Testing, lorsque l’on déploie une fonctionnalité ou un service, il faut suivre :
l’impact sur les métriques identifiées auparavant, on cherche les « tendances »
l’écart avec ses hypothèses, cela permet de se poser les bonnes questions et de tirer les bons enseignements au moment de refaire des hypothèses
l’évolution de la valeur des différents actifs qui composent le produit,
C’est tout l’intérêt de l’approche qui en dépend… Pour finir, il faut garder en tête que cette démarche orientée données est intéressante parce qu’elle pousse à la réflexion autour de vous, améliorant ainsi votre compréhension du marché et celle de vos équipes. Pour autant, nous travaillons tous dans des organisations dont la valeur générée ne correspond pas à la somme des valeurs individuelles de ses produits. Contribuer à, collaborer avec d’autres équipes vous mèneront parfois à faire des choix qui ne favorisent pas la valeur de son produit, ce sont pourtant souvent de bons choix !
