Chères entreprises traditionnelles, vous ressentez peut-être cette sensation de ne pas être assez réactives sur le marché, d'avoir du mal à suivre le rythme effréné des évolutions constantes. Vous avez peut-être constaté que même en ayant bien identifié un besoin utilisateur, la réalisation de la fonctionnalité finale est souvent décevante, laissant vos clients insatisfaits et vous frustrés. De plus, nombre de vos fonctionnalités soigneusement conçues se retrouvent finalement peu utilisées, et vos produits pourtant prometteurs peinent à trouver leur place sur le marché compétitif d'aujourd'hui.

Mais ne désespérez pas. Je vous propose une solution : mettre en place une démarche de discovery adaptée à votre organisation.

Comme je l’expose dans mon article sur le Product Management et les entreprises traditionnelles, l’organisation produit by the book n’est pas une fin en soi, en revanche l’approche produit est une mine inépuisable de bon sens et de bonnes pratiques. Inspirons-nous par exemple de la démarche de discovery.

Le discovery : pour quoi faire ?

Contrairement à une idée répandue dans de nombreuses structures, il est important de souligner que le Discovery ne se résume pas à la simple recherche utilisateur. La recherche utilisateur constitue certes une composante essentielle du processus de Discovery, mais ce dernier englobe un ensemble bien plus vaste.

Le discovery n’a qu’un seul objectif : penser la MEILLEURE solution possible à un VRAI problème utilisateur.

La meilleure solution est celle qui aura été pensée et travaillée en prenant en compte ces quatres critères fondamentaux que sont : la viabilité, l’utilisabilité, la désirabilité et la faisabilité.

Le contenu de cette phase de discovery

Avant d'amorcer la phase de Discovery, il est crucial de garder à l'esprit une réalité indéniable : nous disposons de ressources limitées en termes de temps et de budget pour mener à bien ce processus.
C’est pour cela qu’il va falloir faire des choix sur les sujets à creuser. Je vais vous lister ici toutes les thématiques qui entrent dans la phase de discovery, dans le paragraphe suivant, je vous montrerai comment rendre cette phase efficace en ajoutant un peu de cadre.

Le problème utilisateur

Dans un premier temps, il est essentiel de cibler un problème utilisateur suffisamment important pour que celui-ci justifie l'investissement en temps et/ou en argent dans l'adoption d'une nouvelle solution ou fonctionnalité.

Les problèmes utilisateurs ne sont pas toujours la partie du discovery sur laquelle il faut placer toute son énergie. En entreprises traditionnelles, notamment, la longue histoire avec son marché a créé une proximité qui fait que l’on connaît la plupart des problèmes de nos clients/utilisateurs. Cependant, cette familiarité ne garantit pas toujours qu’on ait trouvé une solution adéquate à leurs besoins.

En revanche, lors de changements majeurs sur le marché tels que l'introduction d'une nouvelle technologie ou l'émergence de nouvelles contraintes légales, il est impératif de consacrer davantage de temps à redéfinir ces problèmes. En effet, dans de tels cas, une attention accrue à la compréhension approfondie des besoins des utilisateurs s'avère essentielle pour proposer des solutions pertinentes et adaptées à l'évolution du paysage commercial.

La solution

Une fois que le problème est validé, il va falloir construire la MEILLEURE solution.

Je suis convaincue que c’est ici que se situe la phase clé de toute conception de produits digitaux. Peu importe que vous soyez ou non organisé en mode produit. Ce qui va compter, à ce stade, c’est votre capacité à travailler en collaboration étroite entre différents acteurs de l’entreprise. Vous devez réunir autour de la table les différentes parties prenantes de l’entreprise qui gravitent autour de votre produit pour construire la solution.
Il faut garder à l’esprit que si une partie est absente de cette phase-là vous mettez en péril la réussite de votre produit.

Si vous n’associez pas le marketing et les sales à la construction de cette solution, c’est que potentiellement vous n’aurez pas anticipé le go to market, le lancement, la capacité à vendre votre produit. Potentiellement, vous pourrez aussi passer à côté de la dimension psychologique de l’acheteur si ce dernier est une personne différente de l’utilisateur.
Si vous n’associez pas la tech à cette phase d’idéation, le risque est très fort d’imaginer une solution totalement irréaliste qui ne verra jamais le jour, ou bien qui, durant la phase de réalisation devra être continuellement adaptée ou revue pour ne plus correspondre du tout à ce que vous aviez imaginé.
Enfin, si vous n’associez pas vos utilisateurs, soit par le biais d’un département UX, s’il existe, soit via une agence qui vous accompagne, soit en intégrant directement des utilisateurs dans votre phase d’idéation, vous risquez de passer à côté de la facilité de prise en main de votre produit.

Comme on le voit ici, cette phase est stratégique.
Le gros challenge va donc être d’arriver à être efficace pour créer ce collectif et s'assurer que la solution réponde bien aux enjeux de viabilité, faisabilité, utilisabilité et désirabilité.

Cadrer votre discovery avec une fiche d’expérimentation

Je vous propose ici un template de fiche, que j’ai créée, qui vous permettra de vous poser les bonnes questions avant de partir en discovery.

J'ai souvent observé des Product Manager se lancer tête baissée dans le processus de discovery, en se concentrant uniquement sur la recherche utilisateur, dans l'espoir naïf que la solution se révélerait évidente après quelques entretiens. Bien que l'engagement à travailler en étroite collaboration avec les utilisateurs soit louable, cela ne devrait pas être le seul fondement du discovery.

Pour lancer la phase de discovery, organiser un atelier avec les Parties prenantes qui gravitent autour du produit et forcer vous à remplir un document avec ces différents items :

FICHE D'EXPÉRIMENTATION

RISQUES A TESTER
Faisabilité :
Désirabilité :
Utilisabilité :
Viabilité Business :

Sur cette première partie, pour un problème utilisateur donné, il va falloir repérer les risques majeurs, l’idée n’étant pas de passer à la loupe l’intégralité des risques mais plutôt ceux qui sont les plus flagrants. On n’est pas obligé de passer en tests utilisateurs (coûteux et consommateurs de temps) pour l’ajout d’un filtre de recherche par exemple.
L’idée est de consacrer son temps sur les points les plus importants, et surtout de prendre cette décision de manière collégiale et assumée.

HYPOTHÈSES À VALIDER

Lors de cet atelier, des premiers éléments de solutions vont être proposés par l’équipe basés sur les connaissances métier, techno. Une série d’hypothèses vont être émises, et c’est cela qu’il va falloir chercher à objectiver.

HYPOTHÈSES ÉCARTÉES

Un certain nombre d’hypothèses vont également être écartées, il est très important de les documenter, et surtout de préciser pourquoi on ne va pas les retenir. Si un jour vous êtes challengé sur “mais pourquoi ne pas être partis dans telle direction ?”, vous aurez alors toutes les réponses déjà prêtes.

EXPÉRIMENTATIONS

Enfin, il va falloir préciser les expérimentations choisies pour valider les hypothèses, qui en est responsable et SURTOUT le temps qu’on se donne en face de chacune d’entre elles pour obtenir des réponses.

Une fois ce document rempli, les expérimentations peuvent commencer. Et la première chose à faire sera alors de prévoir le moment où la fin des expérimentations permettra une prise de décision collégiale sur la meilleure solution possible à la suite de ses enseignements, ou éventuellement le besoin de réitérer sur une nouvelle phase d’expérimentation, à nouveau cadrée, pour valider de nouveaux points.

A l'issue de cette phase de discovery, vous aurez toute la matière pour construire votre solution. Dans un prochain article, je vous présenterai un format de Fiche solution permettant d'aligner toutes les parties prenantes avant de partir en développement.