Product discovery : 6 étapes pour passer de l’intuition au MVP

Qu’est-ce que la product discovery ?

La product discovery est la phase pendant laquelle on cherche à savoir quoi construire. Elle s’oppose au delivery, qui consiste à construire et livrer. L’objectif est de répondre à quatre risques avant d’investir : le produit sera-t-il utile, utilisable, faisable et viable pour l’entreprise ?

Ce n’est pas un luxe réservé aux grandes entreprises. Une discovery de une à trois semaines suffit souvent à éviter des mois de développement mal orientés. C’est d’ailleurs la première étape de mes missions de cadrage.

Étape 1 : comprendre le contexte et les enjeux

Avant de parler solution, il faut comprendre l’entreprise, son marché, ses valeurs et ses contraintes. Pour Vélib’, cela voulait dire analyser la situation de Smovengo : un marché en croissance porté par la mobilité douce, mais aussi un héritage de difficultés laissé par l’opérateur précédent.

C’est aussi le moment d’identifier les parties prenantes : qui décide, qui utilise, qui sera impacté. Une cartographie simple évite d’oublier un acteur clé, comme les équipes logistiques ou le service client.

Étape 2 : faire parler les données quantitatives

Les données disent ce qui se passe. Je commence par un backlog de questions : où sont les problèmes, quand, pour qui, à quelle fréquence ? Puis j’explore les données disponibles pour y répondre, avec SQL ou Python selon les sources.

Sur la mission Vélib’, l’exploration de la base de données a permis de quantifier un problème que tout le monde ressentait : des stations trop souvent pleines ou vides, selon les heures et les quartiers.

Étape 3 : recueillir les retours qualitatifs

Les retours qualitatifs expliquent pourquoi cela se passe. Entretiens utilisateurs, observation terrain, analyse des avis et des tickets du service client : chaque source apporte un éclairage différent.

Pour Vélib’, nous avons combiné un questionnaire auprès des usagers et l’analyse automatisée des avis Trustpilot par webscraping. Croiser ces retours avec les données quantitatives a permis de distinguer les irritants fréquents mais bénins des problèmes vraiment pénalisants pour l’expérience.

Étape 4 : formuler et prioriser les problèmes

À ce stade, on dispose d’une liste de problèmes. Il faut les formuler précisément, par persona, puis les comparer. Un benchmark des solutions existantes aide à voir ce qui a déjà été tenté ailleurs.

Pour choisir, j’utilise souvent un stack ranking : on classe les problèmes du premier au dernier, sans ex aequo. L’exercice oblige à trancher. Sur Vélib’, l’amélioration de la répartition des vélos entre les stations est ressortie en tête. Les autres méthodes de priorisation sont détaillées dans l’article sur la priorisation du backlog.

Étape 5 : concevoir la solution et le MVP

Une fois le problème choisi, on conçoit la plus petite solution capable d’apporter de la valeur et de valider les hypothèses :

• check_circleFormuler des hypothèses testables, avec un résultat attendu
• check_circleÉcrire le MVP sous forme de user stories du type « Le produit doit… », puis les prioriser
• check_circlePrototyper : maquette d’écran, de tableau de bord ou parcours simplifié
• check_circlePour un produit data, cadrer le modèle avec l’équipe data : entrées, sources, décision, métriques
• check_circleDéfinir les indicateurs de succès avant le lancement

Pour Vélib’, le MVP comprenait un algorithme prédisant le ratio optimal entre vélos et places disponibles par station, et un tableau de bord pour les équipes. Nous avons utilisé un Machine Learning Canvas pour aligner l’équipe data et le métier sur ce que l’algorithme devait décider, et sur la façon de mesurer sa performance.

Étape 6 : préparer le lancement et la mesure

Une discovery ne s’arrête pas au MVP. Il faut prévoir comment le lancer et comment savoir s’il fonctionne. Sur Vélib’, la roadmap prévoyait une démonstration aux équipes métier, puis des tests sur quelques zones espacés de deux semaines, avec un formulaire de feedback et un suivi de KPIs comme la satisfaction client (CSAT) et le temps moyen passé hors du bon ratio vélos/places.

Ce déploiement progressif limite les risques et permet d’ajuster l’algorithme avant de l’étendre. La conduite du changement fait partie intégrante de cette étape : un outil n’est réussi que s’il est adopté. Pour aller plus loin sur la mesure, lisez comment construire un dashboard de KPI produit utile.

Les livrables d’une phase de discovery

Une discovery bien menée se conclut par quelques livrables simples, directement utilisables par l’équipe de développement :

• check_circleUne synthèse du problème prioritaire, avec les données et les retours qui le justifient
• check_circleLes personas concernés et leurs principaux irritants
• check_circleUn MVP décrit en user stories priorisées, avec leurs critères d’acceptation
• check_circleUn prototype ou une maquette validée avec quelques utilisateurs
• check_circleLes indicateurs de succès et la façon de les mesurer
• check_circleUne roadmap de lancement, avec les risques identifiés

Ces livrables doivent tenir en quelques pages ou en un tableau partagé. Leur rôle est de permettre une décision rapide, pas de documenter exhaustivement tout ce qui a été appris.

Discovery ponctuelle ou discovery continue ?

On présente souvent la discovery comme une phase qui précède le développement. Dans les équipes produit matures, elle devient une activité continue : chaque semaine, le Product Owner consacre du temps à parler aux utilisateurs, à analyser les données et à tester des hypothèses, en parallèle du delivery.

Pour une PME ou un nouveau produit, une discovery ponctuelle de quelques semaines reste le meilleur point de départ. Ensuite, il suffit d’installer quelques réflexes : un entretien utilisateur par semaine, une revue mensuelle des indicateurs et un formulaire de feedback toujours ouvert.

Les erreurs à éviter pendant une discovery

Quelques pièges reviennent souvent :

• check_circleArriver avec la solution en tête et chercher seulement à la confirmer
• check_circleSe contenter des données sans parler aux utilisateurs, ou l’inverse
• check_circleVouloir tout résoudre en même temps au lieu de choisir un problème prioritaire
• check_circleProduire un document de cinquante pages que personne ne lira
• check_circleOublier de définir comment on mesurera le succès

Questions fréquentes

Combien de temps dure une phase de discovery ? Une à trois semaines suffisent souvent pour un périmètre ciblé. Pour un nouveau produit complet, la discovery peut s’étaler sur plusieurs semaines, en alternance avec les premiers développements.

Qui participe à la product discovery ? Le Product Owner ou le Product Manager, avec idéalement un designer et un développeur ou un data scientist, ainsi que les utilisateurs et les équipes métier.

Que produit une phase de discovery ? Une décision : le problème prioritaire, la solution retenue, un MVP décrit en user stories, un prototype et les indicateurs de succès.