Un processus de découverte produit pour éviter le gaspillage

Le code le plus coûteux est celui que personne n'utilise. Des équipes investissent des mois dans des fonctionnalités livrées proprement, testées avec succès, puis jamais utilisées — parce que le problème a été supposé, pas validé. La découverte produit, c'est le travail peu coûteux que vous faites avant le travail coûteux, pour vous assurer que vous construisez quelque chose dont les gens ont réellement besoin. Elle n'a pas besoin d'être lourde. Elle doit avoir lieu avant le développement, pas après.

La découverte n'est pas une phase, c'est un filtre

On ne fait pas de découverte une seule fois puis on passe à autre chose. Chaque fonctionnalité significative passe par le même filtre : s'agit-il d'un vrai problème, pour de vrais utilisateurs, que nous pouvons résoudre d'une manière qu'ils adopteront ? L'objectif est d'éliminer les mauvaises idées à moindre coût, sur un tableau blanc, avant qu'elles ne deviennent du mauvais code.

Partez du problème, pas de la solution

Les fondateurs arrivent avec des solutions : « il nous faut un dashboard », « ajoutons de l'AI ». Le premier rôle de la découverte est de remonter jusqu'au problème sous-jacent. Que cherche à accomplir l'utilisateur ? Que fait-il aujourd'hui ? Où est-ce que ça coince ?

Si vous n'êtes pas capable d'énoncer le problème en une phrase sans mentionner votre solution, vous n'êtes pas prêt à construire. La solution est une hypothèse ; le problème est ce qu'il faut valider.

Parlez aux utilisateurs avant d'écrire un cahier des charges

Rien ne remplace quelques vraies conversations. Cinq à huit entretiens avec des personnes qui ont le problème vous apprendront davantage que des semaines de débat interne.

• Interrogez-les sur ce qu'ils ont fait, pas sur ce qu'ils feraient hypothétiquement.
• Creusez la dernière fois qu'ils ont rencontré ce problème — les détails concrets valent mieux que les généralités.
• Écoutez les contournements ; un contournement douloureux est la preuve que le problème est réel.
• Résistez à l'envie de pitcher. Vous êtes là pour apprendre, pas pour vendre.

Si personne ne décrit le problème que vous aviez supposé, c'est une information qui vaut bien plus que le développement que vous avez évité.

Validez la demande avant de vous engager

Une fois le problème confirmé, vérifiez si votre solution est souhaitée avant de la construire entièrement :

• Un prototype cliquable présenté à de vrais utilisateurs.
• Une landing page mesurant l'intention d'inscription.
• Un test en mode conciergerie où vous délivrez le résultat manuellement dans un premier temps.
• Une fake-door mesurant le nombre de personnes qui cliquent sur la fonctionnalité.

Ces tests prennent quelques jours et peuvent vous faire gagner des mois. Un prototype qui ne suscite pas d'engagement de la part des utilisateurs, c'est un « non » bon marché.

Écrivez ce qui vous ferait changer d'avis

La discipline qui rend la découverte réelle : formulez votre hypothèse la plus risquée et les éléments qui l'invalideraient. « Nous pensons que les responsables des opérations paieront pour automatiser ce rapport ; nous avons tort si moins de la moitié de ceux à qui nous parlons y voient un vrai coût. » La découverte a désormais un critère de réussite ou d'échec, pas une vague impression.

Alors seulement, cadrez le développement

Quand le problème est validé, la demande est démontrée et les hypothèses ont survécu au contact des utilisateurs, vous êtes prêt à cadrer et à construire — avec bien moins de risque de bien construire la mauvaise chose.

Chez Pykero, nous menons une découverte légère avant d'écrire le moindre code en production, afin que nos clients ne paient pas pour développer des fonctionnalités que leurs utilisateurs n'ont jamais demandées. Si vous êtes sur le point de vous engager sur une roadmap, parlez-nous-en.