Stratégie & organisation
MVP et Product Discovery : pourquoi construire sans valider coûte si cher
Beaucoup de projets produit échouent parce que le problème n'a jamais été réellement validé.
CONTEXTE
Le scénario qui revient trop souvent
Un dirigeant a une idée produit. Il en est convaincu, son équipe aussi. Le développement démarre. Six mois et plusieurs dizaines de milliers de francs plus tard, le produit est livré. Les premiers utilisateurs arrivent. Et ne reviennent pas.
Ce scénario n'est pas rare. Il est même majoritaire. La plupart des projets produit n'échouent pas à cause d'une mauvaise exécution technique. Ils échouent parce que le problème que le produit était censé résoudre n'a jamais été réellement validé avant que le développement commence.
IMPACT
Ce que la phase de découverte permet d'éviter
La Product Discovery, ou phase de découverte produit, est l'ensemble des activités menées avant de construire : recherche utilisateur, identification des vrais problèmes, prototype, test, priorisation.
Son objectif est simple : savoir si ce qu'on va construire vaut la peine d'être construit, et pour qui, avant d'engager un budget de développement.
Plusieurs publications spécialisées l'ont documenté. First Round Review et Lenny's Newsletter citent des cas répétés où l'absence de cette phase a conduit à des refontes complètes après lancement. Le coût d'une correction après développement est en moyenne cinq à dix fois supérieur au coût d'une correction avant.
Trois questions permettent de structurer cette phase :
Quel problème résout-on vraiment ? Pas le problème qu'on imagine, mais celui que les utilisateurs cibles expriment quand on leur parle. Ces deux choses sont souvent très différentes.
Qui est l'utilisateur principal, et comment travaille-t-il aujourd'hui ? Comprendre les workflows existants permet d'identifier où un nouveau produit s'insère, et où il frotte.
Quelle est la solution minimale qui crée de la valeur ? Un MVP n'est pas un produit simplifié. C'est la réponse la plus petite possible à un vrai problème. Tout ce qui dépasse est à ajouter après validation, pas avant.
MISE EN ŒUVRE
Les erreurs classiques dans la phase de découverte
Confondre hypothèse et certitude. "On sait que nos clients ont ce problème" n'est pas une validation. C'est une hypothèse. La validation, c'est quand des utilisateurs réels confirment le problème, idéalement avec leurs mots, pas les vôtres.
Prototyper trop tôt. Certaines équipes sautent directement au prototype avant d'avoir compris le problème. Un prototype testé sur un mauvais problème donne des résultats inutiles.
Prioriser à l'instinct. "Cette fonctionnalité est importante" sans données pour le justifier. La priorisation doit être outillée : impact estimé, effort de développement, niveau de certitude sur le besoin. Ces trois dimensions permettent de faire des choix défendables.
MISE EN ŒUVRE
Comment on aborde ça chez Corraya
Notre Product Discovery Sprint couvre exactement cette phase. En trois semaines, on structure ce que beaucoup d'équipes font en plusieurs mois, souvent de façon désorganisée.
La semaine 1 est consacrée à la recherche : entretiens utilisateurs, analyse des comportements existants, identification des vrais problèmes. On repart toujours des utilisateurs, pas des intuitions.
La semaine 2 produit un prototype testé. Pas une maquette graphique avancée, mais quelque chose de suffisamment concret pour générer des réactions réelles de la part des utilisateurs cibles.
La semaine 3 débouche sur une priorisation structurée et une feuille de route pour la phase de développement : quoi construire en premier, pourquoi, et avec quelle définition du succès.
On travaille avec des PME qui ont une idée mais n'ont pas encore commencé à construire, et avec des équipes qui ont déjà un produit et veulent lancer une nouvelle fonctionnalité sans prendre de risque inutile.
Si vous êtes dans l'une ou l'autre de ces situations, c'est une discussion qui peut faire gagner beaucoup de temps.
