Développer en faisant preuve d’empathie vis à vis du client

« La nécessité est la mère de l’invention ». Ce dicton anglais illustre le caractère immuable de l’esprit humain et notre tendance naturelle à inventer. Comme expliqué dans l’Oxford English Dictionary, « Quand le besoin de quelque chose devient impératif, vous devez trouver des moyens de l’obtenir ou de le réaliser. ». Qui pourrait contredire ces vérités universelles sur l’invention ? Toutefois, comme le décrit l’article Innovation dans l’économie numérique, l’innovation cloud nécessite un juste milieu entre invention et adoption.

Si nous poursuivons l’analogie, l’innovation émane d’un concept plus étendu. L’empathie vis-à-vis du client est mère de l’innovation. Pour créer une solution faisant preuve d’empathie envers le client, qui stimule l’innovation, il faut un besoin légitime du client qui l’incite à revenir pour résoudre des problèmes critiques. Ces solutions sont basées sur les besoins du client et non sur ses souhaits ou ses envies. L’identification des véritables besoins des clients commence par l’empathie et une compréhension approfondie de l’expérience du client. L’empathie est une compétence insuffisamment développée chez de nombreux ingénieurs et chefs produits, voire chez les dirigeants d’entreprise. Heureusement, les différentes interactions et l’évolution rapide du rôle de l’architecte cloud encourage cette compétence.

Comment faire preuve d’empathie envers le client et pourquoi est-ce si important ? L’empathie envers le client vous aide à comprendre et à partager son expérience. Entre le premier lancement d’un produit minimum viable (MVP) et la disponibilité générale d’une solution commercialisable, l’empathie envers le client nous aide à créer de meilleures solutions. Plus important encore, l’empathie permet de mieux positionner l’équipe pour inventer des solutions qui encouragent l’adoption. Dans une économie numérique, les équipes produit qui développent le plus rapidement une empathie envers le client peuvent créer un avenir meilleur avec de meilleurs outils qui redéfinissent et tracent la voie du marché.

Définir des hypothèses pour développer en faisant preuve d’empathie envers le client

La définition des hypothèses est un élément fondamental de la planification. Plus vous planifiez, plus vous voyez clairement vos hypothèses se frayer un chemin vers une grande idée. Les hypothèses ont généralement tendance à être le produit d’une empathie pour soi-même. En d’autres termes, qu’est-ce que je voudrais si j’étais à sa place ? Quand vous commencez par la phase de développement, la période pendant laquelle votre solution est envahie d’hypothèses est plus courte. De plus, cette approche accélère la boucle de rétroaction avec les clients réels, ce qui déclenche des opportunités précoces d’apprentissage et d’affinement de l’empathie.

Attention

Définir correctement ce qui doit être développé peut se révéler délicat et nécessite de la pratique. Si vous développez une solution trop rapidement, elle risque de ne pas refléter les besoins du client. Si vous passez trop de temps à essayer de comprendre les besoins initiaux du client et ses exigences en lien avec une solution, il se peut que le marché y réponde avant que vous ayez eu l’opportunité de développer quoi que ce soit. Quel que soit le scénario, l’opportunité d’apprentissage peut être considérablement limitée ou retardée. Parfois, les données peuvent même être endommagées.

Les solutions les plus innovantes de l’histoire sont nées d’une intime conviction. Ce sentiment intuitif repose sur l’expertise existante et l’observation directe. Commencez par la phase de développement, parce qu’elle permet de tester rapidement votre intuition. À partir de là, nous pouvons cultiver une meilleure compréhension et des degrés d’empathie plus clairs. À chaque itération ou version d’une solution, l’équilibre s’appuie sur le développement de MVP illustrant l’empathie vis-à-vis du client.

Pour assurer cet équilibre, les deux sections suivantes décrivent les concepts de développement dans un esprit d’empathie et définissent le MVP.

Définir une hypothèse axée sur le client

Quand vous développez en faisant preuve d’empathie, vous créez une solution à partir d’hypothèses définies qui illustrent un besoin spécifique du client. Les étapes suivantes formulent une hypothèse qui encourage le développement dans un esprit d’empathie.

1. Quand vous développez une solution en faisant preuve d’empathie, le client est toujours le centre d’attention. Cet objectif peut prendre de nombreuses formes. Vous pouvez prendre pour référence un archétype du client, une personne spécifique ou même l’image d’un client confronté au problème que vous souhaitez résoudre. Et gardez à l’esprit que les clients peuvent être internes (employés ou partenaires) ou externes (consommateurs ou clients professionnels). Cette définition représente la première hypothèse à tester : pouvons-nous aider ce client spécifique ?
2. Comprenez l’expérience client. Développer en faisant preuve d’empathie signifie que vous pouvez appréhender l’expérience du client et comprendre leurs problèmes. Cette façon de pensée reflète l’hypothèse suivante à tester : pouvons-nous aider ce client spécifique à résoudre ce problème surmontable ?
3. Définissez une solution claire pour un problème spécifique. Si vous vous appuyez sur l’expertise des personnes, des processus et des experts, vous pouvez obtenir une solution potentielle. L’hypothèse complète à tester devient : pouvons-nous aider ce client spécifique à résoudre son problème avec la solution proposée ?
4. Arrivez à une instruction de valeur. Quelle valeur à long terme espérez-vous offrir à ces clients ? Cette réponse détermine votre hypothèse complète : comment les clients verront-ils leur vie améliorée en utilisant la solution proposée pour résoudre ce problème surmontable ?

Cette dernière étape est l’aboutissement d’une hypothèse fondée sur l’empathie envers le client. Elle définit le public concerné, le problème, la solution et la métrique d’amélioration à atteindre, le tout étant axé sur le client. Pendant les phases de mesure et d’apprentissage, vous devez tester chaque hypothèse. Anticipez les changements du client, l’énoncé du problème ou la solution à mesure que l’équipe développe une plus grande empathie envers la clientèle potentielle.

Attention

L’objectif consiste à développer (et non planifier) en faisant preuve d’empathie vis-à-vis du client. Vous pouvez très facilement vous retrouver bloqué dans des cycles infinis de planification et d’ajustement pour établir l’énoncé parfait de l’empathie vis-à-vis du client. Avant d’essayer de développer un tel énoncé, consultez les sections suivantes sur la définition et le développement d’un MVP.

Une fois les hypothèses de base démontrées, les itérations ultérieures sont axées sur des tests de croissance en plus des tests d’empathie. Après avoir développé, testé et validé l’empathie, vous commencez à comprendre le marché potentiel à grande échelle. Vous pouvez mieux comprendre votre marché potentiel en développant la formule d’hypothèse standard décrite précédemment. Ensuite, en vous basant sur les données disponibles, estimez la taille du marché total (nombre de clients potentiels).

Puis, estimez le pourcentage du marché total qui rencontre un problème similaire et peut donc être intéressé par la solution. Vous avez alors votre marché potentiel. La prochaine hypothèse à tester est : comment x % des clients verront-ils leur vie améliorée en utilisant la solution proposée pour résoudre ce problème surmontable ? Un petit échantillon de clients révèle des indicateurs clés qui suggèrent un effet en pourcentage sur le pool des clients engagés.

Définir une solution pour tester l’hypothèse

Pendant chaque itération d’une boucle de rétroaction développer-mesurer-apprendre, votre tentative de développement dans un esprit d’empathie est définie par un MVP.

Un MVP représente la plus petite unité d’effort à consacrer (invention, ingénierie, développement d’application ou architecture de données) afin de créer une solution dans une mesure suffisante pour apprendre avec le client. Chaque MVP doit permettre de tester tout ou partie de l’hypothèse précédente et d’obtenir directement les retours du client. Le résultat n’est pas une belle application avec toutes les fonctionnalités qui révolutionne votre secteur d’activité. Le résultat souhaité de chaque itération est une opportunité d’apprentissage, la possibilité de tester une hypothèse de façon plus approfondie.

Timeboxing est un moyen standard de s’assurer qu’un produit reste épuré. Par exemple, vérifiez que votre équipe de développement pense que la solution peut être créée en une seule itération pour permettre un test rapide. Pour mieux comprendre comment utiliser la vélocité, les itérations et les versions afin de définir ce qu’est un produit minimum, consultez Planification de la vélocité, des itérations, des versions et des chemins d’itération.

Réduire la complexité et retarder les spikes techniques

Les disciplines d’invention présentées dans la méthodologie d’innovation explorent les fonctionnalités souvent nécessaires pour produire une innovation mature ou une solution MVP à grande échelle. Utilisez ces disciplines comme guide à long terme pour l’inclusion des fonctionnalités. De même, utilisez-les comme guide de sécurité lors des premiers tests de la valeur client et de l’empathie dans votre solution.

L’éventail de fonctionnalités et les différentes disciplines de l’invention ne peuvent pas toutes être établies en une seule itération. Plusieurs versions peuvent être nécessaires pour qu’une solution MVP puisse inclure la complexité de plusieurs disciplines. En fonction de l’investissement en développement, plusieurs équipes peuvent travailler en parallèle dans différentes disciplines pour tester plusieurs hypothèses. Si vous avez tout intérêt à préserver l’alignement architectural entre ces équipes, n’essayez pas de créer des solutions intégrées complexes tant que vous ne pouvez pas valider les hypothèses de valeur.

C’est en observant la fréquence ou le volume des pointes techniques que vous pouvez le mieux identifier la complexité. Les spikes techniques représentent les efforts à consacrer pour créer des solutions techniques qui ne peuvent pas être facilement testées avec les clients. Quand la valeur du client et l’empathie envers le client ne sont pas testées, les pointes techniques représentent un risque pour l’innovation et doivent être réduites. Concernant les types de solutions matures testées dans le cadre d’un effort de migration, il est courant d’effectuer des spikes techniques tout au long de l’adoption. Toutefois, elles retardent le test des hypothèses durant les efforts d’innovation et doivent être reportées dans la mesure du possible.

Une approche basée sur la simplification constante aide la définition de n’importe quel MVP. Cette approche consiste à supprimer tout ce qui ne vous aide pas à valider l’hypothèse. Pour réduire la complexité, limitez le nombre d’intégrations et les fonctionnalités qui ne sont pas nécessaires pour tester l’hypothèse.

Générer un MPV

À chaque itération, une solution MVP peut prendre de nombreuses formes différentes. Généralement, la seule exigence consiste à obtenir un résultat permettant de mesurer et tester l’hypothèse. Cette exigence simple déclenche le processus scientifique et permet à l’équipe de développer la solution en faisant preuve d’empathie. Cette approche axée sur le client implique que le premier MVP s’appuie uniquement sur l’une des disciplines de l’invention.

Dans certains cas, la voie la plus rapide vers l’innovation est d’éviter ces disciplines (de façon temporaire, mais totale) jusqu’à ce que l’équipe d’adoption du cloud soit convaincue que l’hypothèse est validée avec exactitude. Venant d’une entreprise technologique comme Microsoft, ce conseil peut sembler illogique. Toutefois, cela souligne le fait que les besoins du client, et non une décision technologique spécifique, sont la plus haute priorité dans une solution MVP.

En règle générale, une solution MVP est constituée d’une application ou d’une solution de données avec des fonctionnalités minimales et une finition basique. Pour les organisations bénéficiant d’une expertise professionnelle en matière de développement, cette voie est la plus rapide vers l’apprentissage et l’itération. La liste suivante comprend plusieurs autres approches qu’une équipe peut prendre pour créer un MVP :

• Un algorithme prédictif incorrect 99 % du temps, mais démontrant des résultats souhaités spécifiques.
• Un appareil IoT qui ne communique pas de manière sécurisée dans l’environnement de production, mais qui peut démontrer la valeur des données en quasi-temps réel dans un processus.
• Une application créée par un développeur citoyen pour tester une hypothèse ou répondre à des besoins à plus petite échelle
• Un processus manuel qui recrée les avantages de l’application à suivre.
• Une maquette ou une vidéo suffisamment détaillée pour permettre au client d’interagir.

Le développement d’un MVP ne doit pas nécessiter un lourd investissement en développement. Pour minimiser le nombre d’hypothèses à tester à un moment donné, il est préférable de limiter l’investissement autant que possible. Ensuite, dans chaque itération et avec chaque version, vous améliorez intentionnellement la solution pour qu’elle puisse être développée à grande échelle et représenter plusieurs disciplines d’invention.

Accélérer le développement d’un MVP

Le délai de commercialisation est essentiel à la réussite de toute innovation. Des mises en production plus rapides accélèrent l’apprentissage, ce qui permet une mise à l’échelle plus rapide des produits. Parfois, les cycles de développement d’application traditionnels peuvent ralentir ce processus. Plus souvent, l’innovation est limitée par l’expertise disponible. Les budgets, les effectifs et la disponibilité du personnel peuvent limiter le nombre d’innovations que les équipes peuvent gérer.

Les contraintes en termes de personnel et le désir de développer en faisant preuve d’empathie ont favorisé une tendance de plus en plus forte à recourir aux développeurs citoyens. Ces développeurs réduisent les risques et assurent la mise à l’échelle au sein de la communauté de développeurs professionnels d’une organisation. Les développeurs citoyens sont des experts de l’expérience client, mais ils ne sont pas formés comme ingénieurs. Ils utilisent des outils de prototypage ou des outils de développement plus légers qui peuvent être désapprouvés par les développeurs professionnels. Ces développeurs orientés vers l’entreprise créent des solutions MVP et des théories de test. Quand il est bien aligné, ce processus crée des solutions de production qui fournissent de la valeur sans pour autant passer une hypothèse d’échelle suffisamment efficace. Les équipes peuvent également utiliser les solutions pour valider un prototype avant de le lancer à grande échelle.

Dans le cas d’un plan d’innovation, les équipes d’adoption du cloud doivent diversifier leur portefeuille pour inclure les efforts des développeurs citoyens. En accentuant les efforts de développement, vous pouvez former et tester davantage d’hypothèses avec un investissement réduit. Quand vous validez une hypothèse et identifier un marché potentiel, les développeurs professionnels peuvent renforcer et développer la solution en utilisant des outils de développement modernes.

Dernier obstacle au développement : problématique du client

Quand l’empathie vis-à-vis du client est forte, il doit être facile d’identifier un problème clair. La problématique du client doit être évidente. Au cours du développement, l’équipe d’adoption du cloud travaille sur une solution permettant de tester une hypothèse basée sur une problématique du client. Si l’hypothèse est bien définie, mais que la problématique ne l’est pas, la solution n’est pas véritablement basée sur l’empathie envers le client. Dans ce scénario, le développement n’est pas le bon point de départ. En fait, vous devez d’abord investir dans la création de l’empathie et l’apprentissage auprès des clients réels. La meilleure approche pour créer l’empathie et valider les problématiques est simple : écoutez vos clients. Consacrez du temps à la rencontre et à l’observation de vos clients, et ce, jusqu’à ce que vous puissiez identifier une problématique récurrente. Une fois que vous avez bien compris la problématique du client, vous pouvez tester une solution basée sur des hypothèses pour la résoudre.

Dans quels cas ne pas appliquer cette approche

De nombreuses exigences juridiques, de conformité et sectorielles peuvent nécessiter une autre approche. Cette approche peut ne pas convenir si les versions publiques d’une solution en développement :

• Créent un risque lié aux délais des brevets, à la protection de la propriété intellectuelle ou aux fuites de données client
• Violent les exigences de conformité établies

Quand vous percevez l’existence de ce type de risques, faites-vous conseiller par des experts juridiques avant d’adopter une approche guidée de la gestion des mises en production.

Références

Certains concepts de cet article s’appuient sur des sujets abordés dans The Lean Startup d’Eric Ries.

Étapes suivantes

Une fois que vous avez créé une solution MVP, vous pouvez mesurer la valeur de l’empathie et la valeur de mise à l’échelle. Découvrez comment mesurer l’impact sur le client.

Mesurer l’impact sur le client