Discovery produit : arrêter de construire ce que personne n'utilise

La fonctionnalité la moins chère est celle qu'on n'a pas développée parce qu'on a compris à temps que personne n'en voulait.

Je vois souvent la même histoire dans les petites équipes produit. Quelqu'un a une idée, l'idée paraît évidente, on lance le développement. Trois semaines, deux mois, parfois six mois plus tard, la fonctionnalité est livrée. Et là, silence. Personne ne l'utilise, ou si peu. On se console en se disant qu'il faut « communiquer davantage ». En réalité, le problème était en amont : on n'avait jamais vérifié que le besoin existait vraiment.

Le développement coûte cher, en argent et surtout en temps. Chaque semaine passée à construire la mauvaise chose est une semaine qu'on ne consacre pas à la bonne. Dans une TPE ou une ETI, où les ressources sont comptées, ce gaspillage se paie comptant.

La bonne nouvelle : éviter ce piège ne demande ni budget conséquent ni service produit étoffé. Cela demande une discipline simple, la product discovery, adaptée à la taille de votre équipe.

Discovery et delivery : deux temps différents

La plupart des équipes ne font que du delivery : elles construisent. La discovery, c'est le temps d'avant, celui où l'on cherche à comprendre le problème et à valider une solution avant d'écrire la moindre ligne de code.

Les deux ne s'opposent pas, ils se complètent. Pendant que l'équipe livre ce qui est déjà validé, on prépare et on teste ce qui viendra ensuite. L'idée n'est pas de tout ralentir, mais d'arrêter de développer à l'aveugle.

Concrètement, la discovery cherche à répondre à trois questions avant l'engagement :

• Le problème est-il réel et suffisamment douloureux pour les utilisateurs ?
• Notre solution y répond-elle vraiment ?
• Vaut-elle le coût de développement, au vu du reste de nos priorités ?

Distinguer le problème de la solution

C'est l'erreur de base, et elle est humaine : on tombe amoureux de sa solution avant d'avoir bien posé le problème. « Il nous faut une application mobile » est une solution. Le problème, lui, pourrait être « nos clients n'arrivent pas à suivre l'avancement de leur commande » — et il se règle peut-être par un simple e-mail automatique, dix fois moins cher.

Un réflexe utile : reformulez chaque demande en problème utilisateur avant d'en discuter la solution. Demandez « quel problème cela résout-il, et pour qui ? » systématiquement. Vous serez surpris du nombre de fois où la réponse est floue. C'est justement le signal qu'il faut creuser avant de construire.

Les entretiens clients : la source la moins chère et la plus négligée

Parler à cinq ou six utilisateurs représente quelques heures de votre temps. C'est de très loin le meilleur retour sur investissement en discovery, et c'est ce que les équipes font le moins.

Quelques principes simples pour que ces entretiens servent à quelque chose :

• Interrogez le passé, pas le futur. « Racontez-moi la dernière fois que vous avez eu ce problème » vaut cent fois mieux que « est-ce que vous utiliseriez telle fonctionnalité ? », à laquelle tout le monde répond oui par politesse.
• Cherchez le comportement réel, pas l'opinion. Ce que les gens font compte plus que ce qu'ils déclarent.
• Cinq à sept entretiens suffisent souvent à faire remonter les tendances lourdes. Inutile d'attendre un panel statistique pour apprendre l'essentiel.

La maquette : tester une idée pour quelques heures de travail

Avant de développer, une maquette (même sommaire) permet de rendre l'idée concrète et de la confronter aux utilisateurs. On parle ici de quelques heures de travail, pas de plusieurs jours.

Le principe : montrer plutôt que décrire. Un utilisateur qui manipule un écran, même faux, réagit d'une manière bien plus riche que face à une description orale. Vous verrez tout de suite où il hésite, ce qu'il ne comprend pas, ce qu'il cherche et ne trouve pas.

Selon le degré de finition, une maquette peut aller du simple croquis sur papier à un écran cliquable. Commencez toujours par le niveau le moins coûteux : s'il révèle déjà un problème, inutile d'aller plus loin.

Le test : décider sur des faits, pas sur des convictions

Une fois la maquette en main, faites-la tester par quelques utilisateurs représentatifs. Donnez-leur une tâche à accomplir (« retrouvez le statut de votre dernière commande ») et observez en silence. Ne les aidez pas : leurs blocages sont votre information la plus précieuse.

À l'issue de ces tests, trois issues sont possibles, et toutes sont des succès :

• On continue : le besoin est confirmé, la solution tient la route, on peut développer sereinement.
• On ajuste : l'idée est bonne mais la forme est à revoir avant de lancer le développement.
• On abandonne : le besoin n'était pas là. C'est peut-être le meilleur résultat, car vous venez d'économiser des semaines de développement inutile.

Une discovery à la taille d'une petite équipe

Tout cela peut sembler lourd. Il n'en est rien, à condition de rester pragmatique. Une boucle de discovery utile peut tenir en une à deux semaines : quelques entretiens, une maquette rapide, deux ou trois tests, une décision. Vous n'avez pas besoin d'une équipe de recherche, seulement d'un peu de méthode et de la volonté de vérifier avant de vous engager.

Le vrai changement culturel, c'est d'accepter qu'une idée puisse être abandonnée. Dans une organisation qui mesure sa valeur au nombre de fonctionnalités livrées, dire non est difficile. Dans une organisation qui mesure sa valeur à l'usage réel, c'est une force. C'est tout l'inverse de l'« usine à features », où l'on empile des fonctionnalités que personne ne réclame.

Comment démarrer dès votre prochaine idée

La prochaine fois qu'une idée de fonctionnalité arrive, ne l'envoyez pas directement en développement. Posez trois questions : quel problème, pour qui, comment le vérifier ? Puis consacrez-lui une petite boucle de discovery avant de vous engager. Le surcoût de ces quelques jours est dérisoire face au coût d'une fonctionnalité inutile.

Mettre en place cette discipline sans alourdir votre organisation, c'est l'objet de mon coaching de produit : instaurer les bons réflexes dans votre contexte, avec vos contraintes réelles. Et lorsque le besoin est validé, mon activité de développement sur mesure prend le relais pour construire la solution — cette fois avec la certitude qu'elle servira.

Vous hésitez sur une fonctionnalité avant de vous lancer ? Prenons quelques minutes pour en parler : prendre contact.