Sommaire
Si vous voulez construire un produit numérique, mieux vaut connaître les différentes étapes de la vie d'un produit. Celles-ci peuvent varier en fonction de nombreux facteurs : le type de produit, le marché cible et les stratégies de l'entreprise. Mais la plupart du temps, ces mêmes 5 phases se retrouvent : la product discovery, la product delivery, le lancement, le product growth et le product sunset.
On va se pencher en détail sur la product discovery. Pourquoi ? Parce que c'est la phase qui fait la différence entre un produit que les gens utilisent vraiment et un produit qui finit au cimetière des features inutiles. Et ce n'est pas qu'une image : selon une étude Pendo, 80 % des fonctionnalités d'un logiciel sont rarement ou jamais utilisées. Traduction : des millions d'euros de développement partis en fumée, faute d'avoir validé le besoin en amont.
Ce qu'est la product discovery, comment la mener, avec quels outils, et pourquoi on en a fait un pilier de notre approche chez Drakkar : on fait le tour.
Qu'est-ce que la product discovery ?
La product discovery, c'est la phase amont d'un projet produit. Avant de coder quoi que ce soit, on cherche à comprendre trois choses : quel problème on résout, pour qui, et quelle solution a le plus de chances de fonctionner.
C'est un processus d'exploration et de validation. On part d'hypothèses (sur les utilisateurs, leurs besoins, les solutions possibles) et on les confronte à la réalité du terrain. L'objectif n'est pas de deviner juste du premier coup, mais d'apprendre vite pour réduire l'incertitude.
Marty Cagan, l'un des experts les plus reconnus en product management et auteur du livre Inspired, résume la product discovery autour de quatre questions fondamentales :
- Les utilisateurs veulent-ils vraiment ce produit ? (valeur)
- Arrivent-ils à s'en servir ? (utilisabilité)
- L'équipe technique peut-elle le construire ? (faisabilité)
- Est-ce que ça a du sens pour le business ? (viabilité)
Si la réponse est "non" à l'une de ces questions, mieux vaut le savoir avant d'avoir mobilisé une équipe de développeurs pendant six mois.
Quelle différence entre product discovery et product delivery ?
La confusion est fréquente. La discovery, c'est décider quoi construire. La delivery, c'est comment le construire. Les deux sont complémentaires, mais elles n'ont pas le même objectif.
En discovery, on explore, on teste des hypothèses, on valide (ou invalide) des idées. Le livrable, ce n'est pas du code : c'est de la connaissance. En delivery, on conçoit, on développe, on livre. Le livrable, c'est un produit fonctionnel.
Le piège classique ? Sauter la discovery et passer directement au développement. On croit gagner du temps, mais on finit par construire un produit que personne n'a demandé. C'est ce que Teresa Torres, auteure de Continuous Discovery Habits, appelle le "build trap" : l'obsession de livrer des features sans vérifier qu'elles répondent à un vrai besoin.
Pourquoi la product discovery est indispensable
On ne va pas tourner autour du pot : sans product discovery, vous jouez à la roulette avec votre budget.
D'abord, elle vous protège du gaspillage de ressources. Développer une fonctionnalité qui ne sert à personne, c'est des semaines de travail (et des dizaines de milliers d'euros) perdues. La discovery permet de tuer les mauvaises idées tôt, quand ça coûte encore peu. Elle vous évite aussi les produits hors sol : un produit pensé en salle de réunion, sans confrontation terrain, a toutes les chances de passer à côté du besoin réel. La discovery force le contact avec les utilisateurs. Et elle vous épargne les pivots tardifs et douloureux. Plus on avance dans le développement, plus un changement de direction coûte cher. Mieux vaut pivoter sur un prototype en papier que sur un produit en production.
Mais la discovery, ce n'est pas qu'une protection contre les erreurs. C'est aussi un accélérateur. Vous ne décidez plus sur la base d'intuitions ou de l'avis du HiPPO (Highest Paid Person's Opinion), mais sur des données et des retours terrain. Quand tout le monde a participé à la discovery, tout le monde comprend pourquoi on construit ce qu'on construit - ça change tout en termes de motivation et de cohésion. Et paradoxalement, prendre le temps de la discovery raccourcit le développement. Moins de remises en question en cours de route, moins de features inutiles à maintenir.
👉 Chez Drakkar, on a vu la différence. Sur plus de 80 projets accompagnés, les clients qui investissent dans une vraie phase de discovery arrivent au développement avec une vision claire, des priorités solides et beaucoup moins de surprises en cours de route.
Ce que le terrain nous a appris
Prenons une agence de voyages haut de gamme avec seulement 9 % de réservations en ligne. L'équipe pensait que le problème venait de l'ergonomie du tunnel de réservation. En réalité ? Les clients ne comprenaient pas les offres, les prix et les garanties. Ils appelaient un conseiller pour être rassurés, pas parce que le site était "compliqué". Résultat après discovery : +70 % de conversion, sans refonte majeure.
Autre situation : un site de vente de pneus en ligne. 78 % des utilisateurs croyaient que le site ne proposait pas le montage. Deux semaines de clarification sur la homepage, et la conversion a décollé. Et dans le cas d'une fintech, 6 mois de développement sur une nouvelle fonctionnalité, lancement en fanfare, et... flop total. Personne n'avait validé le besoin auprès des utilisateurs.
Le point commun ? Dans chaque cas, le vrai problème n'était pas là où l'équipe le croyait. C'est exactement ce que la product discovery permet de détecter avant qu'il ne soit trop tard.
Identifiez les besoins et les "pain points" de vos clients
C'est le coeur de la product discovery : comprendre ce que vos utilisateurs vivent vraiment, pas ce que vous imaginez qu'ils vivent.
Comment on s'y prend ? La méthode reine, ce sont les entretiens utilisateurs. Rencontrez vos utilisateurs (ou futurs utilisateurs), posez des questions ouvertes, écoutez. Teresa Torres recommande de mener 3 à 4 entretiens par semaine en continu, pas juste au début du projet. L'idée : maintenir un flux constant d'apprentissage.
Les enquêtes et sondages sont utiles pour quantifier un besoin identifié en entretien. Attention toutefois : un sondage ne remplace pas une conversation. Les gens ne savent pas toujours exprimer leurs besoins dans un formulaire.
L'analyse comportementale complète le tableau. Observez ce que font vos utilisateurs via les analytics, les heatmaps et les enregistrements de sessions. Quel est le cheminement de chaque personne ? Où y a-t-il des blocages dans le parcours ? Les outils comme Hotjar ou Maze vous donnent des données exploitables.
Enfin, les commentaires et feedbacks existants - avis clients, tickets support, réseaux sociaux - méritent d'être épluchés. Vous commencerez à identifier les patterns et à prioriser. Un piège fréquent ici : les tickets support ne représentent que les 10 % d'utilisateurs les plus vocaux. Les 90 % restants partent en silence. Ne basez pas toute votre discovery sur ce canal.
Un outil particulièrement utile à cette étape : la carte d'empathie. Popularisée par le livre Discovery Discipline de Rémi Guyot et Tristan Charvillat, elle permet de structurer ce que vous savez de vos utilisateurs : ce qu'ils pensent, ressentent, disent et font. C'est un excellent moyen d'aligner toute l'équipe sur une vision commune de l'utilisateur cible.
Les étapes clés d'une product discovery réussie
Il n'existe pas une seule façon de mener une product discovery. Les étapes varient selon le contexte, la maturité du produit et les ressources disponibles. Mais voici le processus que l'on retrouve dans la majorité des approches éprouvées.
1. Cadrage et définition des objectifs
Avant de partir explorer, on plante le drapeau : quel problème cherche-t-on à résoudre ? Pour qui ? Quels sont les objectifs business associés ?
C'est le moment de poser la vision produit (où veut-on aller à long terme ?), de définir les métriques de succès (taux d'adoption, satisfaction, rétention) et de tracer le périmètre. On ne peut pas tout explorer : il faut choisir ses batailles.
👉 Chez Drakkar, c'est ce qu'on appelle la phase d'immersion. On se plonge dans le contexte du client : son marché, ses processus, ses équipes. On ne propose rien tant qu'on n'a pas compris la situation dans sa globalité.
2. Recherche utilisateur et analyse de la data
Une fois le cadre posé, on part à la rencontre des utilisateurs. Entretiens, observations terrain, analyse des données existantes. L'objectif : remplacer les suppositions par des faits.
Préparez un guide d'entretien, mais restez flexible : les meilleures insights viennent souvent des digressions. Travaillez en binôme (une personne qui mène l'entretien, une qui prend des notes) et croisez le qualitatif avec le quantitatif. Les entretiens vous disent pourquoi, les analytics vous disent combien.
3. Analyse du marché et des concurrents
L'étude des tendances du marché et l'analyse des concurrents aident à identifier les opportunités et les lacunes qui pourraient être comblées par votre produit.
Identifiez vos concurrents directs, mais aussi les entreprises qui offrent des produits ou services complémentaires. Étudiez leurs prix, leurs stratégies, leurs forces et faiblesses. Prêtez attention au marché global : sa taille, ses tendances, son évolution. Le public cible est-il prêt à accueillir un produit comme le vôtre, ou est-ce prématuré ? Et surtout, déterminez ce qui vous différencie. Si la concurrence est déjà bien implantée, quel angle unique pouvez-vous prendre ?
Le timing, c'est un facteur déterminant dans la réussite d'un projet. Un excellent produit lancé trop tôt (ou trop tard) peut échouer, non pas parce qu'il est mauvais, mais parce que le marché n'est pas aligné.
4. Idéation et priorisation des solutions
Vous avez compris le problème. Maintenant, il faut trouver des solutions. C'est la phase de divergence : on génère un maximum d'idées, puis on converge vers les plus prometteuses.
Pour prioriser, plusieurs frameworks existent. Le score RICE (Reach, Impact, Confidence, Effort) aide à comparer objectivement les idées. La méthode MoSCoW (Must, Should, Could, Won't) est simple et efficace pour classer les fonctionnalités par ordre de priorité. Et l'approche MVP pousse à se poser la bonne question : quelle est la version la plus simple qui permet de valider l'hypothèse ?
5. Prototypage et validation
Le prototypage permet de valider la viabilité d'une idée et de recueillir les réactions des utilisateurs avant d'investir dans le développement.
Commencez par créer des prototypes qui illustrent comment le produit pourrait être utilisé et comment il résoudrait les problèmes identifiés. Les outils sont nombreux : Figma, Adobe XD, Sketch, ou même un simple prototype papier pour les premières itérations. Faites-les tester par vos utilisateurs cibles : pendant une demi-heure à une heure, ils explorent les features et apportent leur feedback. Tester votre maquette avant de développer, c'est un investissement qui paie toujours.
Analysez les résultats pour affiner les spécificités du produit et orienter le développement futur. Et si les tests montrent que le prototype ne répond pas au besoin, pas de panique : on crée de nouveaux prototypes jusqu'à arriver à un résultat qui convient. L'échec d'un prototype n'est pas un échec du projet. C'est un apprentissage.
Les frameworks de la product discovery
Plusieurs méthodologies ont été développées pour structurer la product discovery. Inutile de toutes les maîtriser : choisissez celle qui correspond à votre contexte.
Le Double Diamant (Double Diamond)
Issu du Design Thinking, le Double Diamant est probablement le framework le plus connu. Il se compose de deux phases. Le premier diamant vise à comprendre le problème : on diverge (exploration large), puis on converge (on choisit le problème prioritaire). Le second diamant vise à trouver la solution : on diverge à nouveau (brainstorm de solutions), puis on converge (on sélectionne et on teste).
Le principe est simple : ne cherchez pas de solution tant que vous n'avez pas bien compris le problème. Ça paraît évident, mais dans la réalité, la majorité des équipes commencent par la solution.
Discovery Discipline (méthode FOCUSED)
Développée par Rémi Guyot (ex-CPO de BlaBlaCar) et Tristan Charvillat, la méthode Discovery Discipline propose 7 étapes structurées : Frame, Observe, Claim, Unfold, Steal, Execute, Decide. Chaque étape produit un livrable précis.
Ce framework est particulièrement adapté aux équipes qui cherchent une méthode complète et reproductible. Le livre du même nom est devenu une référence dans l'écosystème produit francophone.
L'Opportunity Solution Tree
Proposé par Teresa Torres dans Continuous Discovery Habits, cet outil visuel permet de relier les objectifs business aux opportunités identifiées, puis aux solutions envisagées. Il force l'équipe à expliciter ses hypothèses et à prioriser en fonction de l'impact attendu.
Le Lean Startup
La boucle Build-Measure-Learn d'Eric Ries reste un classique. L'idée : construire un MVP (Minimum Viable Product) le plus vite possible, mesurer les résultats, apprendre, et recommencer. En product discovery, cette approche est précieuse pour valider rapidement des hypothèses terrain.
Les erreurs qui plombent une product discovery
La product discovery, ce n'est pas magique. Mal exécutée, elle peut même donner une fausse impression de sécurité. Voici les erreurs les plus fréquentes, observées sur le terrain.
"On a fait un benchmark, donc on est alignés." C'est l'erreur la plus répandue. Copier les concurrents suppose qu'ils savent ce qu'ils font. Spoiler : ce n'est pas toujours le cas. Le benchmark alimente la réflexion, il ne remplace pas la confrontation terrain.
"On a posé la question dans un sondage." Un questionnaire ne capture que ce que les gens savent formuler, pas ce qu'ils vivent au quotidien. Il faut aller chercher ce qui n'est pas dit.
Même logique avec les interviews ciblées trop étroites. "On va interviewer 3 commerciaux, ça suffira" : les commerciaux connaissent les objections, pas les usages réels. Ce ne sont pas les utilisateurs finaux. Et le piège des analytics seuls est tout aussi courant. Les données quantitatives vous disent quoi (quel taux de rebond, quel taux de conversion), mais jamais pourquoi. Sans la couche qualitative, vous naviguez à vue.
Il y a aussi le syndrome de la discovery périmée. "On a parlé aux utilisateurs l'an dernier." Mais les usages, les attentes et le marché évoluent. Une discovery n'est pas un livrable figé, c'est un processus continu.
Et le plus sournois : le biais de confirmation. On a une hypothèse, on cherche (inconsciemment) les signaux qui la confirment, et on ignore ceux qui la contredisent. C'est humain, mais c'est dangereux. Travaillez en binôme, faites relire vos guides d'entretien par un tiers neutre, et cherchez activement les signaux faibles qui contredisent vos intuitions.
La leçon de fond : le vrai problème est presque toujours ailleurs que là où on le croit au départ. C'est inconfortable, mais c'est justement pour ça qu'on fait de la discovery.
Qui participe à la product discovery et combien de temps ça prend ?
L'équipe discovery
Une product discovery efficace repose sur une équipe pluridisciplinaire. Le trio de base :
- Le Product Manager pilote la discovery, définit les objectifs et fait le lien avec la stratégie business.
- Le Product Designer (UX/UI) conçoit les prototypes, mène les tests utilisateurs et apporte la vision UX.
- Le Lead Developer apporte la perspective technique et évalue la faisabilité des solutions.
En fonction du projet, on peut y ajouter un data analyst, un expert métier, ou les parties prenantes côté business. L'important, c'est que les profils soient complémentaires et que tout le monde soit impliqué dès le départ.
Combien de temps ça dure ?
La réponse honnête : ça dépend. Mais voici quelques repères :
- Une discovery flash, pour valider une hypothèse simple, dure 1 à 2 semaines.
- Une discovery standard, pour un nouveau produit ou une fonctionnalité majeure, s'étale sur 4 à 8 semaines.
- Une discovery approfondie, face à un produit complexe ou un marché incertain, prend 2 à 3 mois.
⚠️ Attention à ne pas tomber dans le piège de la "discovery éternelle". L'objectif n'est pas de tout savoir, mais d'en savoir assez pour prendre une décision éclairée. Comme on le dit souvent chez Drakkar : mieux vaut une décision imparfaite prise rapidement qu'une décision parfaite qui arrive trop tard.
La product discovery chez Drakkar
Chez Drakkar, la product discovery n'est pas une option, c'est le point de départ de chaque projet. Avant de parler techno, on parle marché, utilisateurs et stratégie.
Notre approche se structure autour d'un cycle éprouvé :
- D'abord, l'immersion. On se plonge dans votre contexte - votre marché, vos processus, vos équipes. On pose les bonnes questions et on écoute les réponses.
- Ensuite, le cadrage. On analyse, on structure, on rédige un cahier des charges clair et partagé.
- Puis la validation. On teste les hypothèses avec des prototypes et on confronte les idées aux utilisateurs réels.
- Enfin, la priorisation. On définit ensemble ce qui doit être construit en premier, sur la base de l'impact business et de la faisabilité technique.
Résultat : quand on passe au développement, tout le monde sait exactement quoi construire et pourquoi. On livre un premier prototype en 4 à 6 semaines et un produit opérationnel en 8 à 12 semaines.
Ce n'est pas un hasard si nos clients mettent systématiquement en avant la même chose : on comprend vite les enjeux, et on accompagne de A à Z. C'est le bénéfice direct d'une discovery bien menée.
Vous avez un projet de produit digital et vous voulez partir sur de bonnes bases ? Contactez-nous, on en discute.
