Continuous Discovery Habits

Référence : Continuous Discovery Habits de Teresa Torres.

Qu’est-ce que le Continuous Discovery ?

Pourquoi faire en continue ?

L’équipe produit se demande constamment s’il construit le bon produit, de la bonne façon, qu’il apporte bien la valeur attendue par le client et pour le business, … L’objectif est de fournir une solution pour répondre à toutes ces questions.

Le terme de Discovery (“découverte”, ou plutôt “Exploration” désigne tout le travail nécessaire à faire en amont, pour trouver quelle valeur apporter au client, tandis que le Delivery (“livraison”) concerne la production de cette valeur. L’idée ici est de mener ces deux grandes étapes en parallèle tout en les faisant constamment interagir.

À ce jour, l’exploration est souvent négligé, au profit de la phase de production. Malheureusement, c’est négliger la propension du produit à évoluer au fil du temps. Le Continuous Discovery vise précisement à permettre de suivre ces évolutions, et surtout ce qui en est la cause (c’est-à-dire les besoins clients, le marché, etc.), en continu.

Quels sont les protagonistes de l’équipe produit ?

La démarche de Continuous Delivery hérite - et prend la suite - de l’initiative Agile, en poussant le concept plus loin, jusqu’à redescendre tout le travail de découverte et d’étude des besoins client dans les équipes produit. L’équipe produit sera composé à minima des rôles suivants :

• le Product Manager et/ou un (ou plusieurs) Product Owner,
• un Product Designer, et
• une équipe technique (grosso modo l’équipe qui va travailler sur le produit).

Il faut voir ces postes comme des rôles, et non des personnes, car une équipe produit peut avoir plusieurs designers, plusieurs experts techniques (et sur des métiers variés), des PO en renfort du PM,… Ces trois rôles sont nécessaires, à la fois dans l’équipe produit, et dans la démarche d’Exploration. D’autres rôles peuvent être nécessaires à l’équipe produit, comme un expert du marché, un analyste data, un commercial, etc. Cependant, ceux-ci ne sont pas essentiels à la démarche d’Exploration (i.e. cela dépend de l’organisation, de la taille de l’équipe, etc. Ils peut aussi s’agir de contributeurs extérieur à l’équipe).

Quel état d’esprit, dans cette équipe ?

1. Centré sur la valeur apportée au client et à l’activité de l’entreprise.
2. Centré sur le client.
3. Collaboration entre les métiers impliqués dans l’élaboration du produit (exploration “et” production).
4. Exploiter le potentiel de la visualisation (graphiques, schémas, etc.).
5. Tirer profit de l’expérimentation, y compris (surtout) des échecs.
6. Intégrer l’idée même de “continuous” dans sa façon de penser.

Ok, on parle de Continuous, mais qu’est-ce que ça veut dire, concrètement ?

Une définition simple pourrait être d’appliquer une stratégie permettant d’impliquer le client dans la recherche et l’élaboration du produit satisfaisant ses attentes, et ce, tout le long du processus d’exploration, et production, du produit.

Le minimum est d’avoir des échanges hebdomadaires avec le client, d’autant plus que, plus le temps passe, entre chaque échange avec le client, plus il y a de risques que la valeur apportée par le produit diverge d’avec la valeur attendue par le client. Et tout l’enjeu sera de tirer profit de ces échanges réguliers avec les clients, pour s’assurer qu’ils permettent réellement de conserver l’alignement avec les attentes du client, sans que ces échanges ne deviennent une perte de temps.

Socle méthodologique

Il y a d’autant plus conflit entre les besoins du business, les bénéfices de l’entreprise, les besoins des clients, et la qualité des services rendus, que ceux-ci peuvent être en contradiction. Cependant, il est possible d’aligner les planètes en partant du principe que le business tire ses profits de la satisfaction du client.

Commencer avec la fin en tête

L’équipe doit avoir une vision claire des intérêts business de l’entreprise pour pouvoir ensuite se concentrer sur les besoins du client, et ainsi rechercher la valeur à lui apporter.

Le point de départ est l’échange avec le client. Un vrai travail de recherche est nécessaire pour identifier le besoin pour lequel on va chercher une solution. Il n’y a pas non plus de solution idéale, seulement des solutions plus ou moins bonnes. Et plus on travail sur la formulation du problème, plus on favorise le choix pour une meilleure solution.

Les besoins, difficultés et désirs des clients doivent être vu comme des opportunités plutôt que comme des problèmes à résoudre, car nous ne visons pas forcément des problèmes à résoudre (le terme exclu tout ce qui est jeu, animation, etc. qui produisent du plaisir) : viser les opportunités ouvre plus… D’opportunités.

Partir d’un champ d’opportunités plus large est une bonne chose, mais l’équipe produit doit ensuite choisir une partie de ce champ, la ou les opportunités bien spécifiques sur lesquelles se concentrer, pour ensuite délivrer la bonne valeur.

La finalité, c’est l’opportunité.

Outcome VS Output

L’objectif est d’être capable de connecter la valeur apportée par le produit à la valeur apportée à l’entreprise. L’outcome concerne la valeur apportée (qualitatif), tandis que l’output concerne la quantité de solutions produites.

Pourquoi l’outcome?

Une équipe produit normalement constituée travail sur la base des besoins du client. Dans ces conditions, il est normal qu’elle ait accès à la valeur apportée par leur solution. D’autre part, cette approche leur rend leur autonomie dans le choix et l’élaboration de la solution adéquate, car l’équipe n’est plus attendue sur la production de fonctionnalités, mais sur leur pertinence pour le client.

Communiquer sur la valeur apportée plutôt que sur les fonctionnalités donne également plus de souplesse à l’équipe produit dans la façon de répondre au besoin (désir) du client. Il est d’autant plus facile de s’engager (i.e. communiquer ) sur une opportunité qu’elle laisse libre cours sur la façon dont on va la satisfaire.

Types d’outcomes

Il existe trois grandes catégories de métriques pour l’outcome. Une fois identifiés, chaque équipe produit élabore ses propres objectifs (product outcomes) qui, une fois mis bout à bout, permettent d’accomplir les objectifs business de l’entreprise.

Business outcomes

Basé sur les données du marché et la situation économique, ces indicateurs doivent être choisis spécifiquement pour donner de la visibilité sur l’état à venir du marché, pas l’état dans lequel il était hier, ou même aujourd’hui, car le but de ces indicateurs est de prendre l’initiative sur les opportunités à venir. Les indicateurs business sont généralement à un niveau supérieur à celui de l’équipe produit.

Product outcomes

C’est la valeur apportée aux utilisateurs, basés sur des indicateurs de l’utilisation de la solution. Avec un suivi régulier, ils permettent d’adapter le périmètre des opportunités et de faire évoluer la solution de façon continue. Ce sont donc les indicateurs dont l’équipe produit a besoin pour travailler au quotidien.

Traction Metric

Il s’agit d’une variante d’objectif pour l’équipe produit, pour lequel le suivi se fait plus sur des fonctionnalités précises, ou sur un intervalle de temps donné. Ce type d’objectif est plus adapté lorsqu’il s’agit de cadrer une équipe junior, pour l’aider à progresser avec une vision claire, ou pour optimiser une fonctionnalité précise, pour bien visualiser le résultat. Par contre, ces métriques ramènent l’équipe produit sur l’output, ce qui peut entraîner une dérive, par rapport au besoin client. Il faut donc être prudent dans leur choix

Remarque : il vaut mieux être un PM expérimenté, avant d’utiliser ce genre de métrique, ou avoir une parfaite maîtrise du produit, pour être sûr que la métrique en question ne sera pas contre productive.

Négociation des outcomes

La décision se fait avec les responsables du produit au niveau de l’entreprise (direction), qui apportent la dimension et les objectifs business de l’entreprise, et l’équipe produit, qui apporte les impératifs et attentes du client sur leur produit, ainsi que ses aspects techniques.

Le responsable produit va aider l’équipe à affiner ses objectifs sans être trop précis (pour éviter de tomber dans l’output), et sans imposer de solution.

L’équipe produit pourra ainsi définir des objectifs à court ou moyen terme, environ 3 mois. Ces objectifs doivent être négociés, c’est-à-dire faire l’objet d’un échange entre l’équipe produit et le responsable, pour que les uns comme les autres aient une vision claire de ce qu’ils impliquent. De même, impliquer l’équipe dans la définition des objectifs l’implique d’autant plus dans leurs réalisations.

Objectifs de qualité

Une bonne pratique est de commencer avec des objectifs d’apprentissage, ce qui permet déjà d’identifier la valeur que l’on souhaite apporter aux clients (outcome). On peut ensuite s’orienter vers des objectifs de performance SMART :

• Specific
• Measurable
• Achievable
• Relevant
• Time-bound

L’ambition de ces objectifs dépend du contexte : le caractère de l’équipe, leur expérience, la difficulté du sujet. Il est néanmoins recommandé d’être prudent et de rester sur des objectifs réalistes (achievable), car les équipes produits sont généralement sur des sujets complexes par nature.

L’équipe ne doit pas avoir trop d’objectifs à poursuivre. Une fois l’opportunité sélectionnée, elle doit se concentrer sur une solution, avec un objectif précis sur la valeur à produire. Courir après trop d’objectifs risque soit de disperser l’effort de l’équipe, soit qu’une partie des objectifs soient négligés, soit un mix des deux. Par contre, l’objectif doit être identifié par plusieurs métriques pertinentes, pour éviter de favoriser un aspect du problème au détriment des autres. Dans le cas de l’acquisition de nouveaux clients, on va typiquement ajouter le suivi de leur satisfaction.

Une équipe produit doit également rester concentrée sur des objectifs apportant la même valeur au client, au moins pour quelques trimestres, et ne pas constamment poursuivre de nouvelles opportunités, sous peine de se perdre et de ne pas capitaliser sur l’expérience acquise.

Découvrir de nouvelles opportunités

Cartographier l’expérience

À partir de la valeur que l’on souhaite apporter aux clients (l’outcome), on va établir le cadre de réflexion, sous la forme du question à propos du client “comment l’utilisateur …”. Le cadre doit être adapté à la portée de la valeur que nous souhaitons apporter : la question doit entraîner des réflexions logiques avec le contexte de l’entreprise, le marché sur lequel elle se positionne, etc. Comme tout le reste, la définition du cadre doit se faire avec l’équipe produit.

À partir de la valeur que l’on souhaite produire, et du cadre établi, chaque membre de l’équipe produit va réfléchir au problème, selon son propre point de vue, sa propre vision sur l’expérience de l’utilisateur. Cette vision devrait être représentée un peu comme un use case de très haut niveau.

Ensuite, les membres de l’équipe produit vont mettre leur vision en commun, pour constituer une cartographie plus précise de l’expérience de l’utilisateur, lors de son utilisation du produit.

Quelques pistes :

• construire une map globale incluant les nœuds et liens que chacun a représenté;
• fusionner les nœuds similaires, en gardant une trace des détails (susceptibles d’être important, pour la suite), éviter de perdre trop de temps à débattre sur leur pertinence;
• ne pas se concentrer seulement sur le meilleur chemin, mais également les fausses routes;
• essayer de capturer le contexte : ce que l’utilisateur voulait faire, pourquoi, comment, (voir son état d’esprit ?)…
• en plus des boîtes et des flèches, utiliser des images pour représenter les idées, souvent plus parlants que de longues phrases (des smileys pour le ressenti des utilisateurs, des icônes pour les éléments techniques, etc.).

Si la cartographie est un bon point de départ, c’est un élément qui doit être régulièrement retravaillé, au fil des échanges avec les clients, des nouvelles solutions mises en place, etc.

Échanger continuellement avec le client

Les clients et utilisateurs ne sont pas forcément en mesure d’exprimer leurs besoins précis, et même s’ils y arrivent, ces besoins en cachent d’autres que l’utilisateur lui-même ignore. Les exemples les plus connus sont Ford, avec l’invention de la voiture quand tout le monde se déplaçait à cheval, ou le premier iPhone, avec l’application voicemail, qui répondait à un besoin que personne n’avait exprimé.

La base n’est pas de demander ce que l’utilisateur veut, mais comment il subvient actuellement au besoin que l’on souhaite adresser. Le fait est que, lorsqu’on demande directement le besoin, l’interlocuteur doit l’extraire de son contexte, et va intuitivement construire une situation fictive basé sur ses émotions, sa personnalité, ses valeurs, etc. plutôt qu’un fait réel, tandis qu’en repartant de l’expérience elle-même, on reconstruit les faits réels avant d’analyser les motivations et besoins. Cela nous rapproche des faits et élague au mieux les biais qui pourraient altérer leur perception.

Lors des échanges avec les clients, il est bon aussi de conserver son profil (poste, rôle, organisation, personnalité, compétences, etc.) permettant d’alimenter les personas sur lesquelles nous pourrons construire des stories, etc.

Les échanges avec les clients doivent être assez fréquents pour suivre les moindres évolutions de leurs besoins, qui traduisent eux-mêmes les évolutions des opportunités. Ces échanges sont également l’occasion de mettre à jour notre cartographie de l’expérience utilisateur, et par la même faire évoluer les choix sur la solution à mettre en place

Bien sûr, il est impossible d’interroger tous les clients à chaque fois. Une bonne base serait d’échanger avec un client chaque semaine, et de simplifier au maximum le processus de choix du client. Le client choisit doit être un utilisateur actif, trouvé soit par des liens dans l’application, des formulaires dédiés, soit en passant par les équipes au contact des clients (support, marketing, etc.).

Des représentants de chaque rôles de l’équipe produit doivent être présents, lors de l’entretien : Product Manager, designer et expert technique. Chacun se concentrera sur un aspect différent du problème du client, et du contexte dans lequel il survient. Et ces aspects permettront d’identifier le cadre du périmètre où l’équipe pourra agir pour faire évoluer son produit.

Tip : comment savoir si le client est en train de parler d’une solution? Lorsqu’on prend l’opportunité, se demander s’il y a plusieurs façons de la résoudre. S’il n’existe qu’une seule solution, alors l’opportunité est une solution.

Constituer l’espace des opportunités

Avant de pouvoir prioriser les opportunités identifiées lors des échanges avec les clients, il faut déjà cadrer l’espace dans lequel elles vont prendre place. La première étape, déjà vue, consiste à élaguer les opportunités pour ne conserver que celles nous faisant avancer dans la direction choisie par la stratégie de l’entreprise. Ensuite, chaque opportunité pourra trouver sa place dans la cartographie des opportunités. Ce placement pourra évoluer au fil des échanges avec les clients et des choix stratégiques de l’entreprise.

Remarque : il est aussi possible de voir émerger des besoins communs entre les clients. On peut donc les rassembler dans les mêmes ramifications.

On peut commencer par une simple liste des besoins, problèmes et désirs des clients. Cependant, on observe rapidement des relations, dépendances, etc. permettant de constituer une arborescence d’opportunités : l’OST.

Sutrcturer et affiner ses opportunités : L’OST (Opportunity Solution Tree)

Le champ des possibilités s’étend à l’infini. Il faut donc partir avec une idée, sur la valeur que l’on souhaite apporter : elle apporte un cadre à la phase d’exploration. Les opportunités peuvent ensuite être organisées sous la forme d’une arborescence, une opportunité plus générale pouvant être dérivée en opportunités plus précises, et les feuilles de l’arbre seront les solutions adressant ces opportunités plus précises.

Exploiter la collecte

Des opportunités pourront être fusionnées, ou plutôt rassemblées sous un intitulé plus générique, suivant l’importance que revêt les distinctions entre ces opportunités pour notre cas (contraintes techniques, stratégie de l’entreprise, etc.). Ainsi, le nœud parent représente une généralisation, et chaque nœud enfant représente un cas pouvant (ou devant) être traité indépendamment des autres.

Sur la base de notre arborescence d’opportunités, nous pourrons les prioriser : en commençant par les feuilles de l’arbre, puis par rapport à l’importance pour la stratégie de l’entreprise. (Remarque : nous pouvons craindre des dépendances, entre les opportunités - les nœuds - au sein de l’arbre, mais si ce dernier est construit proprement ce cas de figure n’est pas sensé apparaître).

Chaque nœud de l’arbre doit être unique, et chaque nœud d’un même niveau doit être totalement indépendant des autres. Si deux nœuds se retrouvent à devoir être traités en même temps, c’est que leurs domaines se chevauchent et que la structure doit être revue. La structure évoluera ainsi à chaque revue de la cartographie, après avoir récolté de nouveaux retours clients, et lors de l’analyse de l’expérience utilisateur. Ces deux moments permettent de refaire le point sur le parcours et les besoins des utilisateurs, et d’ajuster notre arborescence, et ainsi évoluer dans l’élaboration de nos solutions.

Une opportunité, au bas de l’arborescence, doit être suffisamment précise pour être traitée par l’équipe produit. Une opportunité trop vague ne peut trouver de solution précise. De même, un ressenti ou un sentiment ne peut être résolue par une solution, contrairement au problème ou à l’opportunité à l’origine de l’émotion.

À partir des solutions retenues, on définit un ensemble d’hypothèses qu’il faudra valider, pour valider la solution elle-même. Ces hypothèses doivent permettre de garantir que la solution apporte une valeur au client qui induit de la valeur business.

Prioriser les opportunités, non les solutions

De la même façon qu’il faut suivre la valeur produite plutôt que les fonctionnalités livrées, il faut prioriser les opportunités - l’origine de la valeur - plutôt que les solutions - sur lesquelles on développe les fonctionnalités.

Grâce à l’arborescence des opportunités produites précédemment, il est possible de se concentrer sur une opportunité au bas de l’arbre, une feuille, au périmètre circonscrit et suffisamment réduit pour être traité de façon agile. Traiter les feuilles de l’arborescence une à une favorise un processus itératif. Sélectionner la feuille nécessite de commencer par le haut de l’arborescence. Pour chaque niveau, il s’agit de prioriser les nœuds, puis descendre sur la branche prioritaire et recommencer l’opération, jusqu’à avoir sélectionné “la” feuille à traiter.

Prioriser une opportunité peut se faire sur la base de quatre facteurs :

• la taille de l’opportunité, selon le nombre de clients concernés, et en quelle proportion (i.e. si ça a un gros impact sur eux);
• le marché, peut influencer la priorisation, si une opportunité permet de développer l’activité de l’entreprise dans son secteur de prédilection, ou un secteur stratégique;
• l’entreprise, autant sur le plan de sa stratégie, que de ses compétences (la chaîne de valeur), autant au niveau de l’entreprise que de l’équipe elle-même, peut également influencer les choix;
• le client, dans la mesure où nous priorisons les opportunités en fonction de son importance aux yeux de l’utilisateur, et de la satisfaction qu’il a avec sa solution actuelle (typiquement, “won’t do” si l’importance est basse et la satisfaction est haute, “must do” si importance haute et satisfaction basse).

Il vaut mieux éviter de quantifier ses facteurs, pour ensuite classer les opportunités, car il s’agit déjà d’un jugement de comparaison entre elles. De plus, le travail peut représenter une grosse perte de temps. Les chiffres peuvent aussi mener à une assurance mal placée et tuer le débat, qui serait pourtant bénéfique, entre les membres de l’équipe produit, quant à la priorisation des opportunités. De plus, la finesse du découpage de l’arborescence permet de facilement réévaluer nos choix - l’intérêt même du Continuous Delivery - et de potentiellement revenir en arrière et nous engager sur une nouvelle opportunité.

Des avantages de L’OST

Résoudre les tensions entre besoins business et besoins clients

Le business est ce qui donne l’orientation sur le type d’opportunités que l’équipe va adresser, sur le long terme. Il permet donc de filtrer les opportunités offertes par les besoins client identifiés.

Maintenir l’équipe alignée dans sa compréhension

Il oblige les membres de l’équipe à prendre le temps d’analyser les opportunités et à collaborer dans l’élaboration de la solution, plutôt que de se jeter sur le premier problème, et la première solution identifiés.

Façonner la mentalité nécessaire à l’exploration en continu

Il force l’équipe à découper une opportunité aussi vaste que “besoin de kubernetes” ou “demande en PaaS” en de petites briques à taille humaine, dont l’étude est actualisée en continue, qui sont traités en continue, et qui mènent progressivement à fournir la réponse de notre entreprise à l’opportunité de haut niveau.

Favoriser la prise de décision

Le découpage d’une opportunité haut niveau en une série d’opportunités de plus bas niveau nécessite ensuite de prendre une décision sur celles que nous allons adresser, et dans quel ordre. Une fois la démarche bien acquise, elle permet d’éviter les pièges de la prise de décision (focus sur un problème, biais de confirmation, résister à la tentation de s’arrêter au “premier amour”, et la confiance aveugle en son choix). Une solution à ce problème consiste à se demander quels sont les besoins clients les plus importants à résoudre, pour nous, et remettre en question la première solution trouvée, pour en chercher une meilleure. Appliquer le continuous delivery permet également de remettre constamment en question la solution choisie pour l’ajuster sur les besoins.

Accélèrer les cycles d’apprentissage

Le fait d’impliquer l’équipe produit autant dans la phase d’exploration du problème que dans la phase de définition de la solution, avec la capacité à remettre en question la solution, permet aux membres de l’équipe d’apprendre des expérimentations, échecs et réussite, en revenant au problème, pour voir en quoi telle ou telle solution à répondu, ou non, au besoin du client.

Développer la confiance en ce qu’on prévoit pour la suite

La méthodologie favorise le fait de travailler en “bottom-up”, c’est-à-dire d’exploiter les résultats d’expérimentation pour évaluer la qualité des solutions, et revoir l’espace des opportunités. Et ce, en complément de l’approche “top-down”, qui consiste à fournir une définition claire de la valeur à apporter avant de se lancer dans l’élaboration de la solution. Les deux combinés permettent d’avoir des garanties sur la solution finale, et progressivement acquérir de la confiance sur la solution que l’on compte livrer.

Simplifier les interactions avec les parties prenantes

Même lorsque le management laisse suffisamment d’autonomie à l’équipe produit pour élaborer sa solution, il arrive régulièrement des moments où la charge reprend le dessus. Il faut alors être en mesure de montrer de façon claire et concise les progrès de l’équipe. Un OST bien construit permet de remonter ces informations. L’arbre doit montrer de façon claire le cheminement vers la solution retenue, et l’avancement sur cette solution, au travers des expérimentations et des progrès dans sa réalisation.

Les habitudes de l’exploration en continue

L’ensemble des bonnes habitudes permettent d’exploiter les avantages de l’OST, de l’exploration de l’espace des opportunités jusqu’à l’élaboration de la solution retenue, au travers des expérimentations, et d’ainsi en tirer une sorte de roadmap pour anticiper les prochaines actions.

Découvrir les solutions

Développer et exploiter les idées

Le premier réflexe, face à un problème, est de chercher une solution, et généralement, nous prenons la première comme référence, voir nous partons dessus. Cette approche est acceptable pour adresser de petits besoins non stratégiques, comme la méthode de connexion au service, par exemple. Par contre, pour les problématiques plus stratégiques, importantes pour l’activité de l’entreprise, il est nécessaire d’explorer un plus grand nombre de solutions, car plus nous creusons, plus nous sommes susceptible de trouver des idées variées et innovantes, et donc quelque chose apportant une réelle valeur ajoutée.

C’est là que le brainstorming (ou remue-méninges) devient utile. Maintenant, le remue-méninge ne doit pas se faire tel que formalisé à l’origine, car il est uniquement centré sur la session de travail collaborative. Bien que cet échange permette de confronter différentes opinions, elle souffre de biais amenant à réduire les possibilités à réellement innover (se reposer sur les autres, se brider pour se conformer à une tendance générale, etc.). L’idéal est donc de laisser un peu de temps aux membres de l’équipe pour réfléchir chacun à leurs idées avant de les mettre en commun. Les membres de l’équipe disposeront alors à nouveau d’un temps pour réfléchir à leurs idées, mais avec la contribution de chacun, pour terminer sur une phase de sélection en commun. Ce modèle peut être aisément exploité pour toutes les phases de réflexion sur la solution sur laquelle partir.

L’alternance d’échange et de réflexions chacun de son côté peut se renouveler 2 à trois fois, suivant les besoins. L’objectif est d’arriver à 15~20 idées environ, avant de les évaluer (par exmeple par un vote) pour isoler les 3 plus pertinentes.

Après ce premier élagage, les trois idées font l’objet de tests et expérimentations pour, enfin, isoler celle qui sera développée.

Passer à côté des bonnes hypothèses ?

Derrière nos idées se trouvent les hypothèses qui nous ont orienté. Tester les idées prend du temps. De plus, cela revient à prendre le risque de s’attacher à nos idées, et la première confirmation risque de nous cacher ses faiblesses…

La solution sera donc de tester les hypothèses, ce qui implique déjà d’identifier ces hypothèses, avant qu’elles ne donnent naissance à nos idées.

• Hypothèse sur le désir : est-ce que les clients et utilisateurs ont besoin de notre solution (est-ce que ça leur apporte de la valeur) ?
• Hypothèse sur la viabilité : est-ce que ça apporte de la valeur à l’entreprise (i.e. en phase avec au moins un objectif business de l’entreprise) ?
• Hypothèse sur la faisabilité : d’un point de vue technique, légal, sécurité, etc.
• Hypothèse sur le caractère utilisable de la solution : au-delà de répondre au besoin, est-ce que notre solution le fait de façon efficace, ou ajoute-t-elle de la complexité à l’utilisateur?
• Hypothèse d’ordre éthique : respect des donnés personnelles, influences, etc.
• Et enfin, toute autre hypothèse qui pourraient venir pour notre produit (i.e. prendre le temps de réfléchir aux hypothèses spécifiques, dans la mesure où chaque cas possède ses particularités). Chaque idée évaluée doit avoir un minimum d’hypothèses associées à chacune de ces catégories.

Chaque idée pourra soulever des hypothèses différentes, pour chaque membre de l’équipe produit. Une solution pour permettre de s’aligner est d’utiliser le Story Mapping qui consiste à suivre pas à pas le cheminement de l’utilisateur lorsqu’il… utilise notre solution (en supposant que la solution est déjà opérationnelle). Il faut d’abord identifier le (ou les) utilisateur(s) de la solution (au moins deux pour les produits interactif, comme une messagerie, etc.). On va ensuite dérouler les étapes de façon chronologique ou séquentielle (en tenant compte des interactions, si plusieurs acteurs).

NB : Il faut également penser aux étapes optionnelles et aux chemins alternatifs.

Chaque étape identifiée fait l’objet d’hypothèses que nous pourrons ensuite chercher à valider. À chaque fois qu’on a ajouté une étape au parcours, nous avons émis un ensemble d’hypothèses qui doivent être validées pour que notre utilisateur réalise l’action de l’étape. Le parcours en lui-même peut générer son lot d’hypothèses. Il vaut mieux rassembler autant d’hypothèses que possible (20~30 environ), même si certaines paraissent évidentes, pour être sûr de ne pas louper d’hypothèses clé. Ces hypothèses doivent être tournées de telle sorte qu’elle soit favorable à l’idée quand elle est vraie. Elles doivent également être spécifiques à l’idée qu’elles supportent.

On peut également identifier des hypothèses par les moyens suivants :

• faire un pré-mortem : on s’imagine qu’une fois la solution lancée, celle-ci échoue, et cherche à savoir pourquoi;
• parcourir l’OST, depuis la base, en se demandant pourquoi la solution répond à telle besoin, puis pourquoi répondre à telle besoin répond à telle autre (niveau supérieur), jusqu’à remonter à l’opportunité (chaque étape génère une hypothèse à valider).

Ces moyens sont essentiellement informels et servent le temps que l’équipe comprenne comment identifier ses hypothèses. Elles deviendront probablement vite inutiles.

Une fois les hypothèses identifiées, il faut prioriser celles à tester en priorité. Du fait des échanges réguliers avec les clients et des outils vus jusque-là, la plupart des hypothèses seront déjà vérifiées (voir même issues de notre connaissance du client). Pour les autres, nous utiliserons un graphique à deux dimensions :

• l’évidence, pour déterminer si on est confiant ou non dans l’hypothèse, et
• l’importance, ici basée sur le fait que certaines peuvent être contournées, si elles sont fausses tandis que d’autres doivent être validées.

Les hypothèses à la fois peu évidentes et importantes doivent être validées en priorité. Évidence et importances n’ont pas à être précis. Le classement entre les hypothèses sera plutôt relatif (plus ou moins évident/important que telle autre hypothèse).

Tester les hypothèses

Lorsqu’on met en place un test pour une hypothèse, il faut se fixer des objectifs chiffrés pour obtenir des résultats objectifs. Ces objectifs doivent être fixés avant de réaliser le moindre test pour ne pas être influencés par les premiers résultats. L’objectif de base de nos tests est de tempérer les risques pris lorsque l’hypothèse a été émise.

Le test doit également être calibré en fonction de la priorité de l’hypothèse. C’est d’ailleurs pourquoi on ne va tester que les hypothèses à la fois peu évidentes et très importantes, généralement les trois premières sur les 20 à 30 identifiées au préalable. On investira plus de temps, d’énergie et d’expérimentations sur une hypothèse importante. Un test pourra comporter, par exemple, une maquette d’interface, et viser une dizaine d’expérimentateurs. Ce test représentera un investissement de 2 à 3 jours maximum.

Si le résultat est concluant mais qu’on veut réduire le risque, il est possible de faire un second test, en investissant environ une semaine de travail et plusieurs centaines d’expérimentateurs. Il faut tout de même rester modéré dans le temps investi à élaborer une solution de test, au risque de perdre de vue l’objectif initial… Le fait d’avoir commencé par un premier test permet d’éviter d’investir dans le second si les résultats sont déjà significatifs (surtout s’ils sont significativement négatifs).

Nous ne sommes bien sûr pas à l’abri des faux positifs. Cependant, nous sommes en train de tester un ensemble d’hypothèses forcément liées entre elles, et ces tests sont effectués continuellement, étant donné qu’on est dans un processus de continuous discovery, sur une solution qui évolue au cours de son implémentation. Par conséquent, on accumule des points qui, mis bout à bout, permettent de dégager une tendance en même temps que d’éliminer les points qui s’en éloignent le plus. De plus, une certaine rigueur lors de l’élaboration des tests permet de réduire les risques. Par exemple, il faut prendre le temps de choisir les personnes ciblées par les tests (des personnes concernées par le problème que l’on souhaite adressé, intéressé par l’opportunité, etc.).

Les tests peuvent également se résumer à des sondages, même avec une seule question, ciblée, et portant sur le comportement actuel des répondants. Ce genre d’enquêtes peuvent donner de précieux résultats avec des efforts très réduits. À noter que le système doit être conçu pour permettre de prendre en compte les abstentions pour augmenter son efficacité (i.e. connaître le nombre de personnes touchées par le sondage, etc.).

En complément, une bonne stratégie de suivi d’activité permet d’avoir une base de données déjà remplie d’informations permettant de valider certaines hypothèses dès qu’elles sont formulées.

Mesurer l’impact

Une fois une première itération du produit à disposition des clients, nous commençons à recevoir des retours sur son utilisation. Ces retours vont alors alimenter le processus d’exploration, et le processus d’exploration va alimenter les prochaines itérations du produit. Les deux phases, exploration et livraisons, sont donc interdépendantes et ne peuvent être conçues l’une sans l’autre.

Pour tirer le meilleur bénéfice de cette relation, l’idée est d’instrumenter le produit afin d’en tirer des métriques pertinentes. Comme pour le reste, il faut commencer petit et accroître progressivement les métriques, au fur et à mesure des données recueillies et de ce qu’elles nous ont appris. Le choix des premières métriques se basera sur les hypothèses étudiées précédemment, car elles nous aiguillent sur les informations dont nous avons besoin pour la suite.

Nous pourrons ensuite mesurer soit le nombre d’actions réalisées par un utilisateur, soit le nombre d’utilisateurs à avoir réalisé l’action. Le choix se fera selon ce qui apporte le plus de valeur au produit.

Gérer les cycles

L’un des avantages à travailler en cycle d’exploration / exploitation courts, est que partir sur une mauvaise hypothèse aura un coût d’autant plus réduit que, d’une part on aura déjà d’autres pistes à explorer (grâce à l’OST), et d’autre part, l’équipe aura déjà préparé les prochains points, comme les échanges avec les clients, qui pourront être exploités pour creuser directement une nouvelle piste. Il faut donc être près à abandonner une piste qui se révèle mauvaise, ce qui est facilité par les cycles court (i.e. on n’est pas encore trop attaché à notre idée).

Tout l’effort d’analyse réalisé pour constituer l’arborescence des opportunités servira, même si une piste explorée s’avère être amenée à échouer, car les efforts seront rentabilisés pour explorer une nouvelle piste, sur une branche voisine. Il ne faut donc pas hésiter à remonter l’arborescence, si l’équipe voit que son opportunité n’apporte pas la valeur escomptée.

Quand une opportunité paraît encore trop large à traiter, revenir jusqu’aux échanges avec les utilisateurs peut nous aider à découvrir un niveau supplémentaire de découpage. Traiter ces nouvelles opportunités itérativement permettra finalement d’apporter la valeur escomptée.

Partager sur ses résultats

Lorsqu’on partage le fruit de notre labeur avec les parties prenantes, la tendance naturelle nous porte à partager nos solutions, alors qu’il est préférable de repartir du besoin que nous avons adressé.

L’idée est de repartir de l’OST construit pour élaborer la solution, en mettant en valeur le chemin parcouru. Le sommet de l’arborescence étant la valeur marchande recherchée, c’est même l’occasion de s’assurer que nous sommes toujours alignés sur cet objectif. Lors du parcours, des intervenants peuvent même identifier de nouvelles opportunités à explorer, toujours bonnes à prendre.

De la même façon, il faut partager sur la base des outils utilisés : personas pour reconnaître les utilisateurs, scénarii d’utilisation, la priorisation, etc. Et à chaque fois, échanger avec les parties prenantes, en restant ouvert aux suggestions, qui peuvent ouvrir de nouvelles pistes.

Lors du parcours de l’arborescence, on peut le reprendre sous la forme d’un récit, où on présente le protagoniste, ses problèmes, et les opportunités que l’on a identifié pour l’aider. Le but est de fournir suffisamment de matière pour que nos interlocuteurs comprennent notre cheminement, sans s’éterniser, et en utilisant la structure du récit pour que le déroulé soit facile à suivre.

Développer les bonnes pratiques d’exploration continue

Commencer petit, progresser par itération

• Commencer par se forger une idée précise de l’objectif.
• Constituer la base de son équipe (product manager, designer, expert technique), et ne pas travailler seul.
• Prendre l’habitude d’échanger régulièrement avec les clients, petit à petit si besoin.
• Même sans la source, il est possible d’investiguer sur le vrai besoin client, la valeur business souhaitée en posant les bonnes questions aux bonnes personnes.
• Exploiter les retours, lors des rétrospectives de sprint, pour introduire de nouvelles idées, collecter des suggestions, faire évoluer les mentalités, etc.
• Se concentrer sur les idées qui fonctionnent et ne pas s’arrêter sur les points de blocage : les pratiques proposées ne sont pas universelles et doivent être adaptées au contexte de chaque entreprise.
• Même s’il n’est pas possible d’échanger directement avec les clients de son entreprise, il est toujours possible de retrouver des personnes avec des profils similaires (dans son entourage, des meetups, etc.) et donc avec des attentes similaires.

Catalogue des outils

• Arborescence Opportunité → Solution (OST).
• Cartographie de l’expérience (Experience Map).
• Scenarii d’utilisation (Story Mapping) et identification des hypothèses pour chaque étape.
• Priorisation des hypothèses à tester par importance et évidence.

Résumé du parcours d’exploration

Objectif de valeur sur la stratégie de l’entreprise (business) → Objectif de valeur apportée par le produit → Arborescence des opportunités → solutions → Scénarii d’utilisation pour chaque solution → Hypothèses sur chaque scénario et chaque étape du scénario → Tests et sondages sur les hypothèses.