Suivre le cycle de vie de l’innovation
Tailwind Traders se pose des questions sur l’innovation qui affectent également beaucoup d’autres organisations :
- Comment augmenter le rythme des changements sans affecter l’activité ?
- Comment décider où innover et quels changements implémenter pour optimiser le retour métier de ces innovations ?
La réponse aux deux questions est : Tailwind Traders doit intégrer le changement dans sa culture organisationnelle. Une des raisons pour lesquelles les organisations rétives au changement sont souvent frappées par des pannes est que ces changements sont trop grands et ont trop de répercussions. Les changements sont difficiles à tester dans des environnements contrôlés et réalistes.
Si des processus sont établis pour introduire fréquemment des changements, leur taille et les risques associés sont moindres. Cependant, ce processus n’implique pas seulement l’adoption de certains outils ou de certaines technologies. Il nécessite une culture qui encourage le changement et accepte les échecs.
Le concept d’acceptation des échecs peut paraître contre-intuitif, mais il est vital pour le cycle de l’innovation. Si des personnes ont peur de l’échec parce que leurs erreurs vont leur être reprochées, elles ne recherchent probablement pas de nouvelles approches pour résoudre les problèmes à cause de la peur de l’échec. L’ensemble de l’organisation devient alors prisonnière de ses pratiques établies.
Il est possible de mettre en place une culture en mode Fail-fast, où les gens sont encouragés à essayer de nouvelles méthodes. Elles sont habilitées à changer rapidement de direction si elles n’obtiennent pas le résultat escompté, ce qui aide à créer une culture de l’innovation plus riche.
Innovation basée sur des hypothèses
Vous pourriez décrire l'innovation comme un cycle itératif basé sur des hypothèses. Quand vous identifiez l’existence d’un problème, une ou plusieurs hypothèses peuvent être formulées, qui peuvent potentiellement expliquer la cause racine et conduire à la solution. La définition du problème lui-même peut être difficile, car elle doit être mesurable.
Par exemple, la définition du problème « Les clients ne sont pas satisfaits de notre choix de plateformes de paiement » n’est pas mesurable : le problème est donc difficile à résoudre. Si vous pouvez définir le problème sous le forme « 23 % des clients quittent leur session d’achat à l’étape du choix de la plateforme de paiement », vous êtes dans une meilleure position pour mesurer la réussite d’une solution possible.
Une fois que vous avez défini un problème de façon mesurable, vous pouvez formuler des hypothèses candidates pour expliquer et résoudre le problème. Par exemple, une hypothèse pour Tailwind Traders pourrait être décrite ceci : « L’ajout de ContosoPay à nos plateformes de paiement prises en charge réduirait de 23 à 10 % l’attrition clients à la page du paiement ». Maintenant, il y a une idée sur la table, et prendre des mesures en conséquence revient à vérifier sa validité.
Les hypothèses doivent se concentrer sur l’ajout de valeur pour les clients et sur l’amélioration de leur expérience dans leurs interactions avec votre organisation. L’idée est connue sous le nom de empathie client : c’est mettre votre client au centre de votre innovation, et se concentrer sur l’accroissement de valeur pour lui et pour vous.
Il existe de nombreuses façons de valider une hypothèse sans toucher au code de l’application. Les enquêtes clients et les études de marché sont deux exemples de sources d’informations précieuses qui peuvent vous aider à décider de la validité d’une hypothèse. La vérification de ces sources vous permet de qualifier vos hypothèses, et de les établir avec la justesse et la valeur ajoutée métier les plus vraisemblables.
Build
Une fois qu’une hypothèse a un potentiel de valeur suffisant pour être intégrée à votre application, le processus de création démarre. Là encore, la rapidité est cruciale.
Vos sprints de développement doivent être aussi courts que possible. Les conserver sprints permet la vérification ou le rejet rapide de l’hypothèse. Elle peut aussi vous permettre d’optimiser la façon dont les fonctionnalités nécessaires sont intégrées à l’application. Il en résulte des cycles d’innovation plus rapides.
Measure
Vous voulez vérifier l’exactitude de votre hypothèse le plus rapidement possible. Un produit minimum viable est une version préliminaire de la nouvelle fonctionnalité qui recueille un feedback et vous aide à confirmer si vous allez dans la bonne direction.
L’objectif de MVP consiste à vérifier non seulement votre hypothèse, mais aussi les suppositions que vous avez faites. Par exemple, si 23 % des clients de Tailwind Traders quittent le processus d’achat sur la page de paiement, l’hypothèse est que c’est dû au fait que l’entreprise n’offre pas suffisamment de plateformes de paiement. La raison peut cependant être différente. Le produit minimum viable doit être conçu pour confirmer ou rejeter ces suppositions et l’hypothèse.
Learn
La phase d’apprentissage est similaire au début du processus. Une fois que vous en saurez plus sur vos suppositions et votre hypothèse, vous pouvez découvrir qu’elles étaient correctes, partiellement correctes ou erronées. Avoir un état d’esprit orienté vers la croissance et suffisamment d’humilité pour admettre les échecs vous permet de :
- Changer rapidement de cap si nécessaire pour continuer à travailler sur votre produit minimum viable.
- Reconcentrer vos efforts dans d’autres domaines et formuler une hypothèse alternative.
Il est important de réaliser que même si votre hypothèse et vos suppositions étaient erronées, le processus vous a permis d’apprendre quelque chose de nouveau sur vos clients et sur votre activité. Ne pensez pas que c’était du temps perdu. L’important est d’acquérir cette connaissance le plus rapidement possible et de l’appliquer à une hypothèse future. Cette idée est au cœur de la culture Fail-Fast.
Que consulter ensuite ?
La Vue d’ensemble de l’innovation du Cloud Adoption Framework est le meilleur endroit pour commencer à explorer comment innover.