Salut à toi,
J’espère que tu vas bien 😃
Aujourd’hui on va parler de Continuous Discovery, sujet important mais peu traité, notamment dans la littérature produit française.
Pourquoi la discovery est cruciale mais pas suffisante
La Discovery c’est quoi ?
Une première définition
Avant de démarrer sur la Continuous Discovery, définissons dans un premier temps la Discovery 😃
Comme son nom l’indique, on est sur une phase de “Découverte”. Découverte de quoi ? De deux choses :
Du bon problème
De la bonne solution à celui-ci
Plus précisément, à ce stade, on commence à avoir de bonnes intuitions de la direction macro qu’on veut prendre. Cependant, ce n’est absolument pas suffisant pour démarrer des développements directement. On risque de partir dans tous les sens et de ne pas se focaliser sur les bons éléments.
Or, les développements et le temps investi coûtent de l’argent. On veut donc minimiser le risque de gaspiller de l’argent investi pour des fonctionnalités qui n’en valent la peine.
D’où le travail de Discovery.
Le bon problème, la bonne solution
Dans un premier temps, identifier le bon problème va nous permettre de mieux comprendre nos utilisateurs cible et les frictions qu’ils rencontrent au quotidien. C’est important de bien comprendre les endroits problématiques car cela va nous permettre de générer des fonctionnalités plus adaptées, plus rapidement et plus efficacement. Plus largement, les utilisateurs et clients, quels qu’ils soient, vont être toujours plus enclins à dépenser de l’argent pour quelque chose qui répond à un de leurs problèmes, plutôt que pour une solution qui possède des fonctionnalités.
Par exemple, si on veut te vendre un comprimé de doliprane :
Mieux vaut te dire que le comprimé « va t’enlever ton mal de tête en 30 minutes » (problème = mal de tête)
Plutôt que te dire que le comprimé « est composé de paracétamol qui est un vaso dilatateur » (solution = les produits chimiques composant le doliprane).
Dans un second temps, une fois que le problème principal aura été identifié, qualifié et caractérisé, on va pouvoir creuser la solution à mettre en face. Pour un même problème, plusieurs solutions peuvent fonctionner. C’est tout l’intérêt de notre démarche. On va essayer d’identifier la solution qui permet le meilleur compromis entre la valeur délivrée et l’argent / le temps nécessaire pour la construire.
Ce qui ne veut pas dire que cette solution ne va pas évoluer. Bien au contraire, en la construisant de manière itérative on va augmenter au fur et à mesure la valeur délivrée. Tout en étant capable d’apporter un minimum de valeur, vite et rapidement.
Mais est-ce que ça suffit ?
Rappel du cycle de vie produit
Il y a plusieurs manières de structurer la vie d’un produit. Mais schématiquement on retrouve souvent deux phases. Une phase avant de développer (qui contient en général la Discovery). Une phase à partir des développements (qui démarre avec la Delivery).
C’est aussi comme ça que j’aime le représenter. On démarre par un Cadrage puis la Discovery arrive. Ensuite on démarre les développements en phase de Delivery.
Ceci dit, quand on regarde ce processus, cela peut donner l’impression que la Discovery est concentrée à un seul moment dans la vie du produit. “On est entré en Delivery ? On arrête la Disco.” Mais cela serait dangereux pour deux raisons.
Premièrement le travail de Discovery ne doit pas être concentré à un seul moment.
Cela introduirait un déséquilibre préjudiciable au produit.
D’un côté, l’emphase sur la partie Discovery est trop importante lorsque c’est le seul moment où on va aller voir l’utilisateur et comprendre son vrai problème. Aller voir l’utilisateur est une activité essentielle. Or, si on la concentre à un seul moment, cela fait peser beaucoup de pression sur les personnes qui y contribuent. Ce qui risque d’entraîner des conséquences négatives. D’abord, les sponsors risquent d’avoir des attentes surdimensionnées par rapport au résultat d’une phase de Discovery initiale. Ensuite, les acteurs de cette Discovery (PM, Product Designer, Développeur) risquent d’avoir beaucoup plus de mal à converger. L’enjeu est tellement grand. On a l’impression que c’est l’avenir du produit qui va se jouer donc on ne veut pas prendre de décisions à la légère.
De l’autre, une fois la partie Delivery commencée, on risque de complètement occulter toute activité de Discovery. On va se dire « ça va on a passé suffisamment de temps à faire la Discovery ». Donc on va vouloir se focaliser à fond sur l’exécution et la construction des fonctionnalités. C’est un réflexe naturel ! Une fois qu’on a passé du temps sur la Discovery et qu’en plus, c’était LE moment de la Discovery… ça paraîtrait absurde et étrange d’y revenir ensuite. Pourtant c’est dangereux d’éliminer toute activité type Discovery en Delivery. Par exemple, ça va forcément nous amener à réduire les interactions avec les utilisateurs. Or, plus le produit commence à être créé, plus le feedback des utilisateurs est qualitatif. Parce que plus le produit est réaliste, plus les utilisateurs peuvent se projeter sur son usage. Bref, en phase de Delivery, une touche de Discovery a un retour sur investissement très important.
Deuxièmement les choses évoluent, et il faut réussir à le prendre en compte.
Il faut toujours avoir en tête qu’en tant que PM, ton ennemi c’est le manque d’information. Tu passes ton temps à prendre des décisions dans des environnements incertains avec des informations peu fiables
⇒ On lance cette feature, mais on ne peut pas être sûr à 100% qu’elle va marcher, avant de l’avoir développée.
Or plus le temps passe, plus le niveau d’informations augmente. Plus le temps passe, plus notre compréhension de l’utilisateur augmente. Plus le temps passe, plus notre produit évolue et devient réaliste, ce qui renforce la fiabilité du feedback utilisateur.
Donc fatalement, si notre niveau d’informations évolue, les décisions (qui sont basées sur ces mêmes informations) vont évoluer. Telle fonctionnalité qu’on pensait prioritaire il y a 3 mois, n’est finalement pas si importante. Il est donc primordial de pouvoir inclure un peu de Discovery pour s’assurer que les décisions prises vont dans le bon sens pour l’utilisateur.
En matière d’évolution des choses, je pense à deux aspects principaux.
L’évolution des envies / besoins des utilisateurs : comme le dit Ford “si je leur avais demandé ce qu’ils voulaient, ils m’auraient dit des chevaux plus rapides”
La difficulté à anticiper tous les sujets techniques : tu peux être le meilleur ingénieur du monde, tu ne te rendras compte de certaines choses qu’en démarrant les développements et en déployant ton logiciel.
Tout ça plaide donc pour ne pas concentrer la Discovery en phase initiale, à un seul moment, mais de manière plus continue.
C’est tout le but de la Continuous Discovery 😍
Qu’est-ce qu’on entend par Continuous Discovery ?
Ce que c’est
Dans le livre Continuous Discovery (très bon ouvrage que je vous recommande), Teresa Torres la définit comme
La mise en place des moments d’échange hebdomadaires avec les consommateurs pour faire de la recherche et renforcer notre impact
J’aime bien avoir une définition plus liée au cycle de vie. Pour moi, c’est faire de la Discovery en continu, donc y compris une fois qu’on a passé la “première phase de Discovery” et donc, y compris si on a démarré le Delivery.
C’est un point important parce qu’il faut bien être conscient que quand on parle de Discovery et des différentes pratiques à mettre en place, c’est de la théorie. Mais quand tu rejoins une start-up, quand tu rejoins un grand groupe, ou quand tu commences à bosser sur un produit, c’est finalement assez rare que tu doives re-récréer de zéro le produit.
Cela ne veut pas dire qu’il ne faut pas passer par les étapes de Cadrage ou de Discovery, si des développements ont déjà été démarrés pour ton produit. Justement, il faut que tu rebalayes le produit pour t’assurer que :
Les activités du Cadrage ou de la Discovery ont bien été réalisées
Les livrables ont été formalisés et mis à jour
D’ailleurs, c’est une bonne grille de lecture pour identifier d’éventuels trous dans la raquette.
Les livrables et les activité de la Discovery sont nécessaires pour sécuriser que les développements entrepris ne soient pas une perte d’argent car apportant des fonctionnalités qui ne servent à personne. Donc le plus tôt est le mieux, évidemment. Mais mieux vaut le faire, même si c’est tard, plutôt que de ne pas le faire.
En tout cas, cela veut aussi dire qu’il n’y aura probablement pas de période « dédiée » à la Discovery pour vous, pendant laquelle vous pourrez bosser sur le problème, la solution. À tous les coups, il y aura déjà 1 voire quelques équipes de développeurs qui avanceront sur le sujet. C’est pour cela qu’il est important de réussir à inclure de la Discovery dans toute cette ambiance orientée Delivery.
Et c’est exactement le rôle de la Continuous Discovery.
Pourquoi c’est difficile
Avant de rentrer dans les détails de comment on peut mettre ça en place, il faut que je vous prévienne : c’est dur de mettre en place de la Continuous Discovery. Pour vous donner une idée, on va cumuler (i) les difficultés de mettre en place de la Discovery (difficile de converger, difficile d’avoir assez de temps etc…) ; (ii) le stress d’un contexte de Delivery / Growth où les équipes techniques sont sur le pont pour sortir des fonctionnalités. Bref ça n’est pas une mince affaire.
→ Premièrement, on a tous un penchant naturel pour l’exécution.
Les phases de Cadrage et de Discovery sont cruciales et nécessaires. Mais il faut être conscient qu’elles sont aussi très inconfortables pour les Product Managers et les autres personnes qui interviennent dans la construction du produit.
Inconfortables d’abord parce qu’on ne sait pas où l’on va. C’est le but bien sûr. On veut justement clarifier où l’on va… avant d’y aller. Mais cela reste une situation inconfortable. En matière de travail tout le monde préfère les certitudes. Par exemple si je suis dans une start-up, tant que je n’ai pas lancé le Delivery, concrètement ça veut dire que la start-up peut s’arrêter du jour au lendemain parce qu’elle ne permet pas de résoudre un problème suffisamment important.
Inconfortables ensuite parce qu’on est beaucoup confrontés à l’erreur lors de ces phases. Le but de la Discovery c’est de sécuriser les bonnes hypothèses. Or pour identifier des hypothèses valides, il faut également invalider beaucoup d’autres hypothèses. Aussi une phase de Discovery efficace, c’est une phase de Discovery où on a invalidé plein de pistes et donc, où on s’est trompés plusieurs fois. Personne n’aime se tromper ni n’aime avoir tort. Autre élément d’inconfort donc.
Inversement, les phases de Delivery, plus orientées exécution sont très confortables. On peut se mettre en « pilote automatique » et « shipper » / délivrer des features.
⇒ On retrouve de la certitude : il faut développer ce qui est dans la roadmap
⇒ On arrête de se tromper tout le temps : les fonctionnalités qu’on développe sont sécurisées donc on ne fait pas fausse route a priori.
En plus, lors du Delivery, l’équipe produit est beaucoup plus indépendante et isolée du monde extérieur. Il faut évidemment inclure des échanges réguliers avec les utilisateurs lors de démonstrations par exemple. Mais il est assez commun qu’une équipe produit, agile, en delivery, passe 90% de son temps à bosser sans voir trop d’utilisateurs ou de sponsors.
C’est donc le premier élément de difficulté : distiller de la Discovery de manière continue, c’est ramener de l’inconfort dans une phase confortable.
→ Deuxièmement, l’équilibre temporel avec les autres activités est dur à trouver
C’est un problème récurrent sur les phases de Discovery et il n’y a pas de réponses toutes faites. Tout va dépendre du contexte.
Oui il faut passer un certain temps en Discovery avant de lancer les activités de développement de la Delivery pour être sûr que l’argent investi en Delivery permette de développer des fonctionnalités qui apportent de la valeur
Non il ne faut pas passer trop de temps en Discovery au risque de ne pas prendre de décisions et de retarder le moment où on donne accès à l’utilisateur à des fonctionnalités réalistes pour récupérer son feedback.
Dans le cadre de la Discovery classique, cette difficulté est contrôlée par deux éléments.
D’une part, il s’agit toujours d’une Discovery pour ensuite aller vers du Delivery. On a donc un peu « la pression ». Les sponsors qui investissent sur nous, ont en tête une durée pour cette Discovery avant de passer en phase de développement.
D’autre part, la Discovery classique est découpée en des étapes bien définies avec un process assez clair à suivre. On n’a pas forcément trop de questions à se poser sur la méthode ou les activités à réaliser. On suit les différentes phases : problème divergence, problème convergence, solution divergence, solution convergence.
En Continuous Discovery on ne bénéficie pas de ces deux éléments :
Premièrement, ce n’est pas une étape préalable avant d’aller en Delivery puisque la Discovery s’effectue en même temps, en parallèle de la Delivery.
Deuxièmement, on ne peut pas dérouler un process similaire à celui effectué en amont, lors de cette Discovery classique / initiale ; à l’évidence, ces différentes étapes prennent du temps donc on ne peut pas le faire sur chaque fonctionnalité.
La solution qu’on va creuser par la suite, consiste en l’identification de routines et l’utilisation d’outils de manière régulière pour créer une habitude de la Discovery. Faire les choses régulièrement va nous aider à (1) sanctuariser petit à petit ces activités ; (2) mesurer précisément le temps requis pour un résultat optimal afin de s’assurer que tout ça n’empiète pas trop sur le Delivery.
→ Troisièmement, cette Continuous Discovery peut être perçue comme une perte de temps
C’est un écueil auquel vous pouvez être confrontés également. Pour que cette activité de Continuous Discovery soit efficace, il faut investir un minimum de temps. On pourra donc vous reprocher que ce temps investi est une perte de temps.
En particulier deux profils.
D’un côté les utilisateurs. Les activités de Discovery vont nécessiter d’aller échanger avec eux. Pour améliorer notre compréhension du besoin, mais également pour aller tester de nouvelles hypothèses avec eux. Or, nos utilisateurs ont un temps qui est compté. Il faut réussir à les solliciter de manière équilibrée.
En effet, c’est toujours intéressant d’inclure l’utilisateur dans les réflexions tournant autour de l’idéation produit. Au-delà du fait qu’on sécurise les fonctionnalités envisagées, cela permet aussi d’engager l’utilisateur dans la démarche. Si j’ai aidé à construire une fonctionnalité, je serai plus enclin à l’utiliser en pratique ! Ou à en parler auprès d’autres personnes.
Ceci dit, trop de sollicitations peut mener à l’overdose. Donc une bonne pratique peut être de constituer un pool d’une trentaine d’utilisateurs, volontaires pour donner un coup de main de temps en temps. Pour effectuer les activités de Continuous Discovery, il faut piocher dans ce groupe. Certains voudront peut-être encore plus s’impliquer ! C’est top, ça permettra de creuser encore plus. En tout cas on pourra doser et s’assurer qu’on répartit de manière équilibrée la charge.
De l’autre les développeurs. Gardez bien en tête que les activités de Delivery sont intenses et très prenantes physiquement ou émotionnellement pour les développeurs. Déjà parce qu’il y a un stress inhérent au fait de développer les bonnes lignes de code, qui permettent de matérialiser les fonctionnalités du logiciel sans bugs. Ensuite parce que le Delivery s’accompagne de plusieurs facteurs de stress supplémentaires comme les réunions. L’agile implique plusieurs réunions régulières auxquelles doivent assister les développeurs. Ces réunions induisent souvent une charge mentale importante parce qu’ils ne peuvent pas produire de code pendant celles-ci. Il faut donc veiller à ne pas les multiplier pour aider les développeurs à être productif.
Toutefois, les activités de Continuous Discovery vont solliciter les développeurs. On va notamment essayer de les mettre en lien avec des utilisateurs pour qu’ils puissent également avoir des idées de fonctionnalités et nous les pousser. En outre, les idées de fonctionnalités qu’on veut creuser lors de cette phase doivent être analysées et challengées par les développeurs. Cela représente donc un travail supplémentaire là où le delivery « classique » prend déjà beaucoup de temps.
Pour ces deux types de profils, la solution la plus efficace est la plus simple. Il faut simplement expliquer rationnellement et argumenter simplement pour dire en quoi ça n’est pas une perte de temps. Ces activités de Continuous Discovery permettent de sécuriser que :
Les utilisateurs vont recevoir des fonctionnalités pertinentes pour eux
Les développeurs ne vont pas développer dans le vent des fonctionnalités inutiles
Or c’est sûr que les utilisateurs et les développeurs n’aiment pas perdre leur temps. Mais ils aiment encore moins les fonctionnalités inutiles.
Restez solide sur les appuis. Argumentez clairement. Et tout se passera bien.
Comment faire ?
Un outil structurant, les Opportunity Solution Trees
Pour piloter et suivre la Continuous Discovery, on va s’appuyer sur un arbre Opportunité / Solution. C’est un outil extrêmement utile pour réussir à faire de la Discovery en Continu.
→ Première étape initialisation de l’arbre (ou rétro-initialisation)
Il faut se dire qu’1 arbre = 1 produit. Quitte à créer d’autres arbres pour des macro-composants lorsque le produit devient trop gros.
Il faut démarrer par les résultats voulus ou outcomes. On distingue deux types de résultats :
Le résultat business qui est le plus structurant. On ne construit jamais un produit pour le plaisir. On le crée parce qu’on a un enjeu business derrière la tête. Même si l’entreprise est centrée autour du produit parce qu’elle fonctionne par exemple avec un modèle Software as a Service, dans ce cas, il y a toujours tout de même un enjeu plus large, en termes business, en termes de vision. C’est cet enjeu, ce résultat, cet objectif qui doit être mentionné ici. Par exemple pour Uber, il s’agirait d’être la principale alternative de solutions de mobilité pour les habitants des villes par rapport aux transports en commun.
Le résultat produit est la déclinaison du résultat business voulu au niveau du produit. Quel est l’objectif que le produit doit atteindre afin de pouvoir réaliser l’objectif business ? Que ferait le produit dans un monde idéal où il nous aiderait à atteindre cet objectif business ? C’est de ça qu’il s’agit ici. Par exemple pour Uber, ça serait que les applications aient xx nombre d’utilisateurs par jour dans telles villes.
Ensuite on peut décliner sur les étages inférieurs de l’arbre :
Problème : comme on l’a déjà dit plusieurs fois, il s’agit de bien partir d’un problème pour ne pas construire une solution qui ne réponde à aucun problème. Toutefois, il faut être bien clair sur le fait que le mot problème est à prendre ici au sens large. Le mot problème ici peut aussi inclure le fait de combler un désir ou d’aider à exploiter une opportunité. En bref tout moyen d’apporter de la valeur à quelqu’un.
Solution : une fois qu’on a défini des problèmes structurants et pertinents pour nous, on peut commencer à se poser des questions sur les solutions à mettre en face ! D’ailleurs c’est tout l’objectif de la phase de Discovery de trouver ces bonnes solutions. Cependant, à ce stade, on est passé en Continuous Discovery, on va être un peu plus frugal. On va donc identifier plusieurs pistes de solution qui nous semblent pertinentes sans forcément passer autant de temps que dans une Discovery classique.
Expérimentation : les solutions représentent une quantité toujours non négligeable de temps, d’argent ou d’énergie investie. Pour éviter de se lancer tout de suite dans leur construction, on va identifier des expérimentations pour sécuriser au maximum que notre idée est pertinente. De la même manière qu’en Discovery, pour un problème macro, on va évaluer la pertinence de la solution à travers un prototype. Ici, on va évaluer la pertinence d’une solution à travers une expérimentation. L’objectif en revanche, est de pouvoir obtenir des informations fiables sur cette pertinence en y passant moins de temps qu’en phase de Discovery / prototypage.
À ce stade, on a donc un arbre qui commence à être rempli avec un résultat business voulu, sa déclinaison côté produit. Puis ensuite, quelques problèmes (2-3 pas plus au début) et des pistes de solution pour chaque problème (2-3 par problème donc 6-9 solutions en tout). Sachant que comme c’est présenté sur le schéma, on a parfois 2 voire 3 étages de problème. Pour chaque piste de solution, on définit une expérimentation.
Notre arbre est initialisé !
→ Deuxièmement tracer toutes les idées
Avant de rentrer dans l’opérationnalisation de la démarche, il est important de préciser l’importance de tracer et noter toutes les idées qui peuvent vous venir tout au long du cycle de vie du produit. En particulier lorsqu’on rentre en Continuous Discovery. Or, cette structure de pensée est extrêmement pertinente pour stocker les idées.
Je pense à un problème récurrent mentionné par les utilisateurs, je crée une bulle sur l’arbre puis on verra où et comment la rattacher par la suite
Je pense à une solution demandée tout le temps par les développeurs et les clients, je la fais apparaître dans la partie solution.
C’est également pertinent pour présenter aux sponsors les travaux réalisés et les actions en place pour réaliser la vision business et ses résultats associés. Retenez bien que c’est toujours le point qui intéresse le plus les chefs : est-ce que la vision business est claire ? Est-ce que je suis susceptible de voir des résultats pertinents rapidement ? L’OST est une excellente manière de les rassurer sur le sujet.
En outre, cela va plus loin. L’OST facilite l’alignement entre les membres de l’équipe et leur donne la possibilité de contribuer au processus de priorisation et de définition des fonctionnalités du produit. C’est un outil très démocratique. Tout le monde peut suggérer une idée : UX Designer, Product Manager ou Développeur.
→ Troisièmement revoir régulièrement et déployer
En pratique, voici quelques idées pour implémenter efficacement cet outil. Ce sont des opinions personnelles qui n’engagent que moi. Mais je pense qu’elles constituent une bonne base pour démarrer.
En premier lieu, il faut répartir l’arbre entre les différentes équipes qui vont intervenir dans le construction du produit.
S’il n’y a qu’une seule équipe produit, alors c’est plus simple, l’équipe entretient et anime son propre arbre.
S’il y a plusieurs équipes produit, dans ce cas, il faut focaliser chaque équipe sur 1 voire 2 problèmes maximum pour ne pas les surcharger de travail.
Il faut s’assurer que la ou les équipe(s) qui hérite(nt) de problèmes ont la possibilité de les résoudre concrètement. Par exemple, si j’ai un problème lié à l’infrastructure qui est instable ce qui fragilise l’application, on va donner ce problème à une équipe ayant une forte composante DevOps et infra.
En deuxième lieu, chaque équipe doit intégrer une revue de cet arbre lors de chaque sprint agile (~ toutes les 2 semaines comme on va le voir par la suite). Cela doit faire partie des cérémonies du sprint. En général en agile, on inclut une réunion pour travailler sur le backlog et le mettre à jour. À mon avis, cette réunion peut très bien être fusionnée avec une réunion de revue de l’OST. L’objectif de cette réunion est de faire le point sur (1) les différentes idées récupérées précédemment ; (2) les expérimentations en cours et leurs succès éventuels ; (3) les nouvelles expérimentations à lancer.
Il est pertinent d’associer cette réunion avec une réunion pour revoir le backlog parce que si une expérimentation est concluante, dans ce cas on va souvent prioriser la solution correspondante dans les prochains sprints. Donc l’inclure au backlog.
En troisième lieu, il est important de remettre à plat l’arbre de manière moins fréquente. Entre tous les 3 ou 6 mois, il faut revoir l’arbre et notamment les principaux problèmes et le résultat produit (outcome) voulu. C’est aussi un bon moment pour faire deux choses :
Se demander si on ne peut pas améliorer la manière de gérer l’arbre, et être le plus en mode « amélioration continue »
Partager les grosses priorités entre équipes (lorsqu’il y en a plusieurs) pour éviter du travail en silo
Enfin, en termes d’outils, je dirais que ça n’est pas le sujet le plus sensible ou le plus important. Mais il faut un outil collaboratif comme ceux qui permettent de faire des brainstormings pour que tout le monde puisse facilement rajouter des tickets et qu’on ne soit pas limités par la place comme sur PowerPoint. Un outil comme Miro ou Figjam fonctionne bien.
Passer à l’action
On va voir quelques idées pour enclencher la démarche de Continuous Discovery, en plus d’initialiser l’arbre comme on l’a vu au-dessus. Je me suis librement inspiré de Continuous Discovery Habits de Teresa Torres que j’ai évoqué plus haut.
1️⃣ Prendre du temps avec les stakeholders
Pour leur expliquer l’importance du processus de Continuous Discovery.
D’une part, il est nécessaire de bien se mettre d’accord sur les résultats qu’on veut obtenir. Ces fameux outcomes ! Bien souvent, lorsqu’une entreprise peine à atteindre ces résultats c’est :
Soit que ces résultats ne sont pas bien définis
Soit que ces résultats n’ont pas été communiqués clairement aux équipes
C’est donc primordial de bien prendre le temps d’expliciter ces enjeux avec nos stakeholders. En général, ils ont des profils de type « investisseur » avec une vision très claire des retours sur investissement attendus. Cela donne l’avantage d’avoir déjà un besoin d’objectiver les choses. Pour autant, il faut aller plus loin puisque les outcomes business et les outcomes produit ne sauraient se réduire juste à des augmentations de chiffre d’affaires ou de taux de marge.
Pour faire cela, il est nécessaire que le Product Manager accompagné d’autres profils Product de l’organisation lance un processus de négociations avec (1) les stakeholders ; (2) les équipes concernées.
De cette manière, on s’assure que tout soit co-construit et que chacun ait eu son mot à dire. Au-delà du fait que ça permette de commencer à imprimer ces enjeux / objectifs / outcomes, c’est aussi une manière de leur donner plus de légitimité.
D’autre part, comme vu auparavant, les stakeholders peuvent identifier la Continuous Discovery comme une activité qui va détourner les développeurs du fait de produire. Et non comme une activité qui va leur apporter de la valeur puisque ça va sécuriser le fait que les investissements consentis sont attendus des clients. Or sans soutien de leur part :
Déjà il va être très difficile d’emporter celui des équipes techniques ou des autres équipes impliquées « si même les sponsors trouvent que c’est inutile, pourquoi je le ferais ? »
Ensuite on pourra peut-être réaliser quelques actions de Continuous Discovery mais à la moindre urgence de production, à la moindre incartade ou mini problème à ce niveau, on va jeter le bébé avec l’eau du bain.
Pour autant les sponsors sont toujours rationnels quand on leur parle le langage de l’argent à savoir, investir x€ pour récupérer y€. Ainsi il serait déraisonnable de leur part de ne pas soutenir une démarche de Continuous Discovery quand on leur a bien expliqué. Soyez donc clairs sur la valeur que ces actions apportent comme vu au-dessus (j’espère que vous en êtes convaincus à ce stade).
Ensuite, le processus de définition des outcomes voulus est également en soi, une manière de montrer la valeur ajoutée de la Continuous Discovery. Elle nous pousse à nous poser les bonnes questions, les vraies questions : qu’est ce que je veux avoir comme impact ? Quels sont mes objectifs ? Comment je le mesure ?
2️⃣ Objectiver documenter mesurer
Il s’agit ici de deux aspects cruciaux de la gestion de l’information :
La collecte de l’information
L’exploitation de l’information
D’une part, il faut s’assurer que notre organisation parvienne correctement à collecter toute l’information qui peut lui être pertinente pour s’améliorer. Il s’agit de l’ensemble des documents, des éléments ou des données, qui sont produits tout au long de la vie de l’organisation :
Documents comme les livrables clés du produit (user journey, persona, Stratégie produit…) mais aussi les compte-rendus de discussions
Éléments comme les user stories dans notre logiciel de backlog ou comme les scénarios de tests…
Données comme les statistiques d’usage du produit ou le taux de conversion de notre landing page…
⇒ On ne doit (peut) pas tout mesurer : mieux vaut itérer progressivement 🔄
D’autre part, il faut garantir qu’on arrive à exploiter efficacement cette information pour identifier si nos actions ont un réel impact. Cela veut dire être dans une attitude très proactive vis-à-vis des éléments de mesure dont on dispose. Et avoir des relations très fluides avec les équipes techniques qui vont nous aider à implémenter ces nouvelles sondes pour remonter de la data. Un aspect important est notamment la mise en qualité de la donnée. Souvent on remonte beaucoup de donnée mais celle-ci n’est pas très utile car pas forcément compréhensible ou intelligible. Il est crucial de s’assurer qu’on comprenne bien le contenu des bases de données générées.
Enfin, c’est une étape incontournable de se rendre compte de l’importance de la mesure et de la donnée pour nous aider dans nos arbitrages produit. Toutefois, il ne faut pas rentrer dans une démarche maximaliste qui pourrait nous bloquer : on ne peut pas tout mesurer. Ou en tout cas, on ne peut pas tout mesurer du jour au lendemain. Il faut itérer progressivement. Démarrer avec ce qu’on a, essayer de l’optimiser, rajouter d’autres éléments petit à petit. Ce qui fait la différence ce n’est pas d’être obsédé à fond par le sujet pendant 2 semaines non stop. Ce qui fait la différence c’est d’y passer 10-15 minutes par jour, tous les jours, pendant 6 mois, pendant 1 an.
3️⃣ Stimuler la créativité
La créativité est centrale dans le processus de Continuous Discovery. On a besoin d’avoir des idées pour tester de nouvelles choses tout le temps et améliorer notre produit petit à petit. Si on devait définir plus précisément la créativité, cela renvoie au fait d’avoir des idées nombreuses, diversifiées et originales. Ainsi on constate que cette créativité renvoie à la fois à des aspects quantitatifs et qualitatifs.
En matière d’idéation ou pour stimuler la génération d’idée, les brainstormings sont très souvent mis en avant comme l’outil ultime. Il peut être, je pense, pertinent avec les utilisateurs. Il l’est moins en équipe, de manière régulière, dans une démarche de Continuous Discovery.
C’est probablement un peu trop chaotique pour être organisé chaque semaine, chaque sprint. Et à force de connaître l’exercice, on peut le faire de manière plus paresseuse en jouant un peu moins le jeu. Encore une fois, cela ne vaut pas pour les brainstormings en face de Discovery Solution avec les utilisateurs. Les utilsiateurs justement ne sont pas « blasés » ni habitués à ce type d’atelier. Il conserve donc toute sa valeur dans ce cadre.
Je préconise donc d’avoir (1) une boîte à idées pour stocker toutes les suggestions possibles et imaginables émanant des équipes ; (2) un moment pendant le point « Continuous Discovery » de chaque sprint pour discuter de nouvelles idées potentielles.
Quelques conseils pour stimuler la créativité :
Premièrement, la quantité amène la qualité. Je le sais notamment de par mon expérience de créateur de contenu sur LinkedIn, dans ma newsletter ou sur Instagram. J’ai créé beaucoup de contenus (pas loin de 1000) en un an et demi. Et je sais une chose : personne n’est exceptionnel du premier coup. Ou en tout cas c’est tellement rare, qu’on ne doit pas miser sur cette anomalie statistique. Les meilleures idées viennent parce qu’on a eu beaucoup d’idées. Mieux vaut avoir 100 idées de niveau moyen que 10 idées de bon niveau. D’abord parce que la qualité des idées dépend de l’utilisateur dont on ne peut pas anticiper a priori les réactions. D’autre part parce que si notre muscle créatif sait générer 10 fois plus d’idées, l’impact sera beaucoup plus important lorsqu’on améliore la qualité de celles-ci. Très vite on arrivera à générer 100 idées de bon niveau.
Deuxièmement, ne pas négliger la force des pauses. Souvent les meilleures idées viennent dans les moments creux. Pas pendant le brainstorming qui était censé nous aider à en avoir. Par exemple, sous la douche, en vélo, en marchant au calme dans la rue… En plus, le cerveau respire pendant les pauses ce qui permet à notre muscle de la créativité de se reposer pour revenir en pleine forme. Les pauses fonctionnent aussi très bien de manière collective. Elles permettent à l’équipe de prendre du recul.
Troisièmement, aller regarder d’autres domaines. Il y a beaucoup à aller chercher dans d’autres secteurs, d’autres industries, d’autres activités. J’adore les analogies. D’abord elles permettent d’expliquer des choses complexes de manière simple. Ensuite elles donnent plein d’idées (si on fait ça dans tel contexte, pourquoi on n’essayerait pas de le transposer dans le nôtre). Évidemment toute analogie est fausse, mais l’objectif n’est pas d’être exact, plutôt de stimuler de la bonne manière notre cerveau pour qu’il génère les bonnes réflexions.
Quatrièmement, regarder les utilisateurs extrêmes. Les utilisateurs dits extrêmes sont ceux qui ont un rapport le plus intense, fort avec le produit. Un utilisateur normal d’un vélo fait du vélo 1 fois par semaine. Un utilisateur extrême en fait 10h par jour. L’intérêt d’aller voir ces utilisateurs extrêmes est qu’ils expérimentent des problèmes liés au produit de manière beaucoup accentuée que les autres. Si les pneus du vélo ne sont pas assez solides, je vais le voir très très vite à hauteur de 10h de vélo par jour. Ça va donc nous donner plein de super idées d’opportunités à aller chercher pour pousser les utilisateurs « normaux » à renforcer leur utilisation de l’outil – sans pour autant devenir forcément des utilisateurs extrêmes.
Enfin quoiqu’il arrive, soyez indulgents envers vous-mêmes. Rome ne s’est pas faite en un jour. Il faut démarrer, et avancer petit à petit. Ça peut mettre du temps, mais si vous arrivez à ne pas faiblir et à garder le rythme. Vous changerez le monde 💪
Conclusion
Merci de m’avoir suivi dans ce voyage autour de la Continuous Discovery. J’espère que ça t’a été utile. On se retrouve la semaine prochaine 🙏
On se retrouve la semaine prochaine pour le prochain numéro !
Si tu es trop impatient pour attendre, tu peux :
Me contacter pour échanger sur la Continuous Discovery par mail ou par message LinkedIn 💪
M'envoyer des feedbacks sur ce numéro, positifs... ou négatifs bien sûr ! C'est comme ça qu'on progresse 💪
Partager la newsletter à des personnes susceptibles d'être intéressées 💪
Bon courage pour la semaine 😃
Victor
Whaou ! Super complet, bravo !