Comment industrialiser la Product Discovery ?

La Product Discovery est une activité essentielle au succès d'une organisation Produit. Il permet de garantir la satisfaction des besoins clients, et, plus globalement, de minimiser les risques associés au lancement d'un produit. Son importance dans la stratégie produit peut cependant être sous estimée et il n'est pas toujours bien ancré dans les processus Produit. Dans cette article, Alexandre Irrmann-Tézé, directeur général de Thiga, nous livre les clés d’un Product Discovery efficace, et les méthodes pour faciliter sa mise en oeuvre et son adoption au sein de toute l'organisation. 

Les activités de Product Discovery consistent à identifier des besoins utilisateurs, étudier des opportunités de solution Produit. C'est aussi s’assurer que celles-ci soient pertinentes tant pour l’utilisateur que pour l’entreprise. En tant que CPO ou Lead Product Manager, j’ai le sentiment que l'on réalise ces activités de manière trop sporadique et peu structurée.

Mes équipes mènent des tests utilisateurs de temps en temps. Nous avons également fait un premier exercice de constitution de personae.

Pourtant, les activités de Product Discovery sont cruciales pour la réussite d’un Produit. En effet, elles permettent de limiter les risques pris et de concevoir au plus près des besoins utilisateurs. J’aimerais pouvoir les industrialiser ; c’est-à-dire les accomplir de manière récurrente et à l’échelle dans l’entreprise, pour alimenter plusieurs squads en parallèle.

Pour exceller en Product Discovery : Inscris-toi à notre formation Discovery Discipline

Nous proposons la création d’une équipe dédiée aux activités de Product Discovery. Elle s’appuie sur les différentes squads Produit pour les aider à dérisquer les sujets de long terme.

Cette équipe utilise un certain nombre de méthodes inspirées des mouvances Design Thinking ou Lean Startup. Elle doit dans l’idéal permettre de limiter au maximum les risques en un minimum de temps. Cependant, elle ne doit pas empiéter sur l’autonomie des différentes squads. 

Le domaine du Product Management peut globalement se découper en 3 grandes activités :

• Discover : identifier une opportunité et définir la vision du Produit ou de la fonctionnalité y répondant
• Build : construire et développer le Produit et l’expérience utilisateur associée
• Grow : préparer l’organisation à commercialiser le Produit et faire croître la base utilisateurs via des mécanismes d’acquisition et de rétention

Ces 3 activités sont toutes cruciales à la réussite d’un Produit numérique. Elles sont également cycliques et s’appliquent à tous les niveaux du Produit ; c’est-à-dire que chaque fonctionnalité ou release passe normalement par ces 3 phases successives.

Pourtant, nous observons que la plupart des organisations se focalisent extrêmement sur le Build, aux dépens parfois des activités Grow et surtout Discover. La Product Discovery est en effet moins couvert par la littérature existante et complexe à passer à l’échelle ; comme on le verra plus loin dans ce chapitre.

Pour aller plus loin : Découvre notre livre sur les organisations Produit

Une boîte à outils inspirée du Design Thinking et du Lean Startup

La Product Discovery est un ensemble d’activités qui consiste à identifer des besoins utilisateurs ou des opportunités de marché. Il définit des hypothèses portant soit sur le besoin, soit sur la solution, puis les tester, en amont du développement.

Exemple de case study Product Discovery 

Par exemple, pour le cas d’un Produit de site de rencontre dédié aux sportifs. Il peut y avoir plusieurs Hypothèses Besoin :

• Une 1ère Hypothèse Besoin peut être : la pratique d’un sport est un critère important dans les relations amicales ou amoureuses
• Hypothèse Besoin 2 : les solutions existantes sur le marché sont insuffisantes par rapport à ce cas d’usage donné
• Hypothèse Besoin 3 : les sportifs sont spécialement friands de solutions digitales

Et plusieurs Hypothèses Solution :

• Hypothèse Solution 1 : les sports pratiqués doivent être mis en avant sur les fiches personnelles de chaque utilisateur
• Hypothèse Solution 2 : le MVP peut se focaliser sur la course à pied car il s’agit du sport le plus communément pratiqué
• etc…

En général, il faut commencer par définir un cas d’usage, une idée exprimée sous forme de besoin utilisateur. Parfois l’idée porte directement sur une solution. Auquel cas il est important de se poser la question du “pourquoi ce Produit a-t-il du sens” :
Quel est le besoin qui se trouve derrière la solution proposée ?

Créer un canevas associé au cas d’usage, utilisateurs

Pour matérialiser ce cas d’usage, et toujours dans l’optique d’industrialiser la démarche Discover, nous vous suggérons de créer un canevas à remplir. Tout comme un Lean Canvas, ce brief évoluera tout au long de votre processus de conception. Il deviendra ainsi progressivement enrichi et amendé pour aboutir au résultat final. Il s’agit également d’un outil de communication très intéressant en interne pour savoir sur quels sujets chacun travaille et pour avoir rapidement une vue synthétique des projets de moyen-terme de l’entreprise. 

Le canevas que nous proposons se compose de plusieurs parties. Néanmoins, n’hésitez pas à ajuster cette fiche en fonction des besoins et spécificités de votre Produit et organisation.

• Cible utilisateurs : en général, le ou les personae concernés par le cas d’usage ; ou les critères discriminants qui permettent d’identifier les utilisateurs impactés par ce cas d’usage.
• Problèmes rencontrés : la description du problème utilisateur. Dans un premier temps, vous pouvez remplir cette partie en vous mettant dans la peau de l’utilisateur final, de manière théorique ; vous pourrez ensuite challenger et compléter cette description après avoir rencontré de vrais utilisateurs.
• Retours utilisateurs : des verbatims (qualitatifs) ou métriques (quantitatives) qui justifient et prouvent le problème utilisateur.
• Hypothèses à tester : une liste des principales suppositions que vous avez faites en remplissant le canevas. Cette liste définira les tâches à effectuer pour le processus de Discover. Il vous faudra les prioriser, en choisissant les plus risquées d’abord ; celles qui peuvent faire s’effondrer votre idée si elles se révèlent fausses.
• Valeur attendue : pour l’entreprise comme pour le client. Remplissez-la le plus objectivement possible ; cela permettra de prioriser les sujets entre eux, et de mettre de côté rapidement les sujets à faible valeur ajoutée.
• Avantage compétitif : pourquoi c’est VOUS et vous seul qui pouvez réussir à résoudre ce problème utilisateur (matérialiser ce cas d’usage).
• Adhérences & dépendances : d’autres projets en interne qui peuvent impacter ce cas d’usage, ou des équipes qui travaillent sur des sujets similaires.
• Concurrence : qui sont vos principaux concurrents sur ce besoin utilisateur.
• Effort de dérisquage : l’effort consenti pour dérisquer ce sujet (temps alloué, ressources affectées…).

Maintenant que vous avez un cas d’usage formalisé, l’étape suivante consiste à valider ou invalider chacune des hypothèses établies. La première action (et souvent la plus importante) consiste à vérifier que les utilisateurs sont bien conformes à l’idée que vous vous en faites, et que le besoin que vous estimez certain l’est vraiment.

Kanban pour le processus de Product Discovery

Pour cela, vous devrez probablement mêler recherche qualitative et quantitative. Aller rencontrer des utilisateurs, voire vous immerger dans leur milieu ; éplucher les retours utilisateurs, étudier les analytics.
Vous devrez vous appuyer sur cette matière pour creuser le besoin utilisateur ; et ainsi mettre à jour vos personae et vos Jobs to Be Done, suivant l’approche que vous préférez.

Une fois que vous aurez validé (et sans doute au passage considérablement approfondi) le besoin utilisateur, il est temps de se pencher sur la partie Solutions. Organisez un brainstorming en conviant un maximum de profils différents : experts du marché, forces de vente, PO ou PM, développeurs. Si vous aviez déjà en tête des solutions dès le départ, faites l’effort de les mettre de côté pour repartir d’une page blanche ; cela permet de plus se libérer dans la réflexion. Il est aussi également probable qu’après avoir travaillé le besoin, la solution initiale s’avère ne plus y répondre tout à fait.

Les solutions proposées peuvent se rédiger sous forme d’epic ; par exemple si vous êtes organisés en SAFe, ou en Feature Teams. Toutes ces epics ne se développeront pas au final. Dans une logique de MVP, vous allez devoir prioriser les idées qui permettent d’apporter le plus de valeur. Elles doivent néanmoins rester réalisables dans un temps réduit.

Après avoir priorisé une idée répondant au besoin utilisateur, ambitieuse mais faisable, et s’appuyant sur les forces de votre entreprise ou votre organisation, nous vous conseillons de prendre un peu de temps pour réfléchir au modèle économique de ce Produit ou cette fonctionnalité. Beaucoup d’entreprises et notamment de startups reportent ce moment à plus tard et préfèrent se lancer au plus vite ; cependant, nous considérons qu’il n’y a pas besoin d’investir des semaines d’effort dans un business plan détaillé pour se faire une première idée. Une rapide étude d’opportunité
(à commencer par vérifier que le marché cible est suffisamment important pour que le Produit puisse survivre) peut souvent suffire, et aidera à emporter l’adhésion du management. Anticiper les problématiques de modèle économique permet aussi de faire les bons choix de conception dès le début.

La dernière étape consiste à tester cette idée de solution auprès des utilisateurs. Construisez un prototype, si possible interactif, et testez-le. Si les résultats sont excellents, félicitations, il y a de grandes chances pour que le Produit donne de bons résultats. S’ils sont moyens, prenez en compte les différents retours utilisateurs. Revoyez ensuite votre copie : affinez la solution. Le cas échéant creusez de nouveau le besoin pour voir si vous n’êtes pas passé à côté de quelque chose. Si les tests du prototype sont mauvais, ou que vous n’arrivez pas à emporter l’adhésion après plusieurs essais, laissez tomber et passez à une autre idée. Archivez le prototype, qui pourra peut-être resservir plus tard (si le marché se développe ou les besoins utilisateur évoluent).

Vous pouvez également découper ce board en 2 parties distinctes. L’une concerne les cas d’usages (et s’arrêtant au stade du brainstorm des solutions). L’autre traite les epics (et embarquant toutes les phases jusqu’au développement).

Les exemples sont nombreux sur les différents app stores, dans les colonnes des magasines technos ou sur Startup Graveyard. Trop de Produits se révèlent des solutions à des problèmes qui n’existent pas (rappelez-vous les Google Glass), ou ciblent les mauvais utilisateurs, ou encore ne trouvent jamais leur modèle économique. Bien sûr, aucune méthodologie, aussi sophistiquée soit-elle, ne vous prémunira à 100% contre l’échec ; mais de nombreux problèmes peuvent souvent s'anticiper et se résoudre en quelques semaines de travail bien structuré.

Pour aller plus loin : Mets en place une bonne organisation Produit

Qui prend en charge la démarche de Product Discovery dans l’entreprise ?

En général, la plupart des entreprises pratiquent la Product Discovery, dans une certaine mesure. La difficulté consiste à industrialiser cette approche au niveau de l’entreprise. Appliquer les méthodologies décrites ci-dessus est à la portée de n’importe quelle organisation ; arriver à le faire systématiquement, à bon escient, au bon niveau, et sur l’ensemble des sujets Produit est une tâche plus complexe.

En pratique, les entreprises adoptent souvent 2 options organisationnelles qui sont, à notre sens, tout aussi contre-productives l’une que l’autre.

Le non-choix : l'absence de réelle Product Discovery

Dans certains cas, personne ne se saisit réellement du sujet dans l’organisation, par peur de l’échec ou résistante culturelle ; en général, on se retrouve dans une logique top down où quelques personnes (souvent le fondateur, ou le CPO) imposent leur loi et se contentent de suivre leur intuition. Certains prennent l’initiative de faire des tests utilisateurs, des prototypes. Cette démarche se heurte néanmoins aux urgences et priorités fixées d’en haut. Le résultat est souvent incohérent et ne permet pas de construire un vrai flux tiré de dérisquage.

Le Product Owner multitâche

D’autres entreprises sont conscientes de l’importance de dérisquer un sujet avant de le lancer en conception. Elles confient cette tâche au Product Owner d’une équipe Scrum. Cela peut fonctionner dans une certaine mesure, surtout si le Product Owner a une appétence pour l’expérience utilisateur et le “Design Thinking”. Mais cela n’est pas optimal et conduit souvent les activités Discover à passer à la trappe. En effet, le Product Owner d’une équipe Scrum jongle entre les urgences et les demandes contradictoires. Il peut également avoir tendance à se retrouver le nez dans le guidon, avec la contrainte de préparer ses prochains sprints et de délivrer régulièrement de la valeur pour l’utilisateur ; il n’est pas rare qu’il ait du mal à concilier les 2 temporalités, court terme et long terme. Du coup, le flux de cas d’usage dérisqués ne suffit plus à alimenter les équipes Scrum.

Par ailleurs, le Product Owner et son équipe se focalisent par nature beaucoup sur le Build. Ils ont alors une orientation “solution” et une propension à construire puis tester après coup.

Quand une démarche de conception ou de Product Discovery est bien mise en place, c’est généralement un coup d’essai en début de projet, pour construire le Minimum Viable Product. Après quoi, on repasse souvent à un pilotage mélangeant intuition et gestion des urgences.

La solution : une équipe dédiée au Product Discovery

La solution la plus pertinente, si l’on souhaite que ces activités de conception Produit et de Product Discovery s'exécutent de façon appropriée, à l’échelle, et pérenne dans le temps, est selon nous de construire une équipe dédiée.

Cette équipe se constitue de Product Managers, souvent organisés en différents domaines fonctionnels (tribus, dans le cas de Feature Teams). L’idée est de s’appuyer sur l’expertise des Product Owners, développeurs ou Product Designers présente dans chaque squad ; l’équipe Product Discovery n’impose pas aux équipes de développement des idées “venues d’en haut”. Néanmoins, elle les aide en travaillant sur des sujets de long terme qui arriveront in fine dans leur backlog. Elle sollicitera donc volontiers les membres des squads concernées par le sujet étudié ; que ce soit pour un brainstorm, une étude de faisabilité, ou un atelier de sketching.

Exemple d'organisation en Product Discovery

Elle apporte également une couche de transversalité dans l’organisation. Pour cela, elle se saisit de sujets impactant potentiellement plusieurs Feature Teams (et encore plus dans le cas d’équipe components).

L’équipe Product Discovery n’a pas non plus le monopole de la méthodologie Discover. Elle ne coupe pas les différentes squads de leur relation avec les utilisateurs. Tous piochent dans une boîte à outils commune, utilisée par les Product Owners et les Product Designers dans leur squad pour tester et concevoir leurs fonctionnalités ou évolutions de court terme (horizon : quelques sprints), et par l’équipe Product Discovery pour préparer ce qui arrivera dans le futur.

Aussi, ce qui se met en place ressemble à une double logique de sprint, avec un processus de Product Discovery (sur un temps plus long) et des squads travaillant sur un temps plus court ; mais les 2 cycles doivent être interconnectés et participatifs, pour éviter de retomber dans du cycle en V déguisé.

Exemple de processus de Product Discovery en mode sprint

Nous suggérons toutefois d’inclure des profils de Product Designers directement au sein de l’équipe Product Discovery ; l’aspect recherche utilisateur et prototypage sont en effet des activités très importantes. Les Product Designers des différentes squads sont alors souvent trop peu disponibles pour être sollicités sur des sujets de long terme. Par ailleurs, il peut arriver que l’équipe Product Discovery travaille sur des sujets qui ne rentrent (pour l’instant) dans le périmètre d’aucune squad : avoir un Product Designer directement dédié permet de préparer le terrain.

On peut ajouter à ce schéma un troisième cycle : celui de la démarche Growth (voir le Product Academy volume 2 pour en savoir plus). Elle vise à expérimenter à haute fréquence pour améliorer petit à petit le Produit. Cette démarche peut être portée par la squad et son Product Owner, dans le cadre du cycle de delivery ; mais on peut aussi créer un troisième cycle d’expérimentations à haute fréquence, encore plus rapide que le cycle Scrum et porté par un Growth Marketer ou une équipe Growth dédiée.

Combien de temps dure le processus de Product Discovery ?

Par nature, les activités que nous décrivons ci-dessus sont parfois assez chronophages et ne sont jamais techniquement “terminées” : on peut toujours creuser un peu plus le besoin, faire une itération supplémentaire sur un prototype ou relancer une session de tests utilisateurs.

Pour autant une équipe de Product Discovery ne peut pas se permettre de s’appesantir pendant des mois sur un ou deux cas d’usage. S’il est difficile de déterminer à l’avance le temps à investir sur un sujet donné, nous vous suggérons tout de même de doser l’effort. Pour cela, 3 critères peuvent s'envisager :

• Le niveau de risque : le risque est essentiellement lié à l’impact de ce sujet sur votre business. Une expérimentation assez facile à développer, sur un sujet annexe à votre business mais potentiellement intéressant présentera peu de risque. La refonte de votre parcours de souscription ou le lancement d’un tout nouveau Produit sur lequel vous fondez de grands espoirs sera un projet plus risqué.
• Le niveau d’urgence : quand espérez-vous pouvoir commencer à développer le cas d’usage envisagé ? 1 mois ? 3 ? 6 ?
• Le niveau de connaissance existant sur le sujet : si vous êtes raisonnablement certain de vos hypothèses, que vous disposez de plusieurs études de marché ou de grandes quantités de retours utilisateurs facilement accessibles, vous pouvez vous permettre d’aller plus vite vers les conclusions et les solutions.

Nous vous suggérons de définir 3 “typologies” de cas d’usage, et de dimensionner l’effort en fonction :

• Les cas d’usage très risqués et exploratoires ; vous aurez tendance à investir du temps et de l’énergie en Product Discover sur ces projets-là
• Des cas d’usage modérément risqués, sur lesquels vous avez des doutes ; fixez une deadline dans un futur proche pour faire un premier bilan de la phase de discover
• Les cas d’usage urgents ou très peu risqués ; prévoyez un processus plus rapide (quelques semaines)

Le plus simple consiste à cadencer votre équipe Product Discovery en sprints, comme une équipe Scrum. C'est aussi d’allouer un certain nombre de sprints de conception à chaque type de projet. Il est parfois difficile d’évaluer en amont le niveau de risque. Aussi n’hésitez pas à prévoir pour chaque projet une première semaine d’exploration. Affinez ensuite éventuellement le niveau d’urgence ou de priorité.

Il peut d’ailleurs être intéressant de mener en parallèle des sujets assez simples à dérisquer mais à fort impact et des sujets stratégiques plus long-termistes.

Dans tous les cas, la Product Discovery ne doit pas rentrer dans un niveau de détail trop élevé. Le risque est de limiter l’efficacité et l’implication des squads qui prendront la suite. L’idée est de dérisquer quelques hypothèses importantes, si besoin au moyen de prototypes. Ce n'est pas de dicter une solution prêt-à-développer à des équipes qui se centrent sur le delivery.

N’oubliez pas que construire soi-même la solution n’est qu’une possibilité parmi d’autres, et pas toujours la meilleure. Si le sujet est risqué, complexe, ou potentiellement coûteux en développement, la phase de Product Discovery peut aussi servir à identifier des potentiels partenaires techniques voire des cibles de rachat. S’il s’avère qu’un acteur tiers répond parfaitement bien au besoin que vous avez identifié, ou qu’un acteur propose une solution en SaaS appropriée, le partenariat peut être une solution économique, au moins le temps de valider l’appétence de votre marché.

Do's and Don'ts de la Product Discovery

Si ce n’est pas déjà fait, nous vous encourageons à recruter des Product Managers et créer une équipe Product Discovery au sein de votre entreprise. Votre Produit ne pourra s’en porter que mieux. Voici quelques éléments pour vous aider à implémenter ce processus dans votre organisation. 

Pour exceller en Product Discovery : Inscris-toi à notre formation Discovery Discipline