Un entrepreneur pose une question. « Est-ce possible ? »

La tentation est de sauter tout de suite aux solutions : quel logiciel existe pour cela, combien coûterait un développement, qui pourrait construire ça. Ce sont toutes des questions qui deviennent pertinentes à un moment donné — mais pas en premier. Entre un client qui demande quelque chose et un produit qui vaut la peine d'être construit ou vendu, il y a pas mal d'étapes.

Un client décrit d'ailleurs rarement un problème produit. Il décrit ce qui lui manque aujourd'hui. Celui qui demande une app en a peut-être surtout assez d'un processus qui passe par cinq e-mails et trois tableurs. Celui qui veut sa propre plateforme s'intéresse souvent moins à la technologie qu'à la marge, aux données clients ou au contrôle de la relation client. Et celui qui cite une fonctionnalité qu'il connaît d'une grande plateforme ne vise parfois que l'effet de cette fonctionnalité — pas la fonctionnalité elle-même.

Si l'on prend la solution demandée au pied de la lettre, on peut très bien construire exactement ce qui a été demandé et pourtant résoudre le mauvais problème.

C'est pourquoi je commence par décortiquer ce genre de demande. Que doit vraiment pouvoir faire le client final ? Que doit-il se passer en interne pour que ce soit possible ? Qu'est-ce qui doit être en temps réel, et qu'est-ce qui ne doit absolument pas l'être ? Et de quelle dépendance l'entrepreneur veut-il précisément se débarrasser — et quelle nouvelle dépendance achète-t-il à la place ?

Ce n'est qu'une fois cela clarifié que la technologie devient intéressante. Et même alors, je trouve que « c'est possible » est une réponse maigre. Presque tout peut être construit si le temps et le budget ne comptent pas. La vraie question commerciale est de savoir si c'est sensé. Existe-t-il déjà quelque chose qui résout une grande partie du problème ? Deux systèmes existants peuvent-ils, ensemble, faire ce qu'un seul nouveau système devrait faire ? Qui doit l'utiliser au quotidien, et que se passe-t-il quand quelque chose tourne mal ? Et l'avantage reste-t-il plus grand que la complexité qu'on y ajoute ?

C'est là que commence pour moi l'opportunity validation : non pas prouver que l'idée de départ était bonne, mais essayer de découvrir pourquoi elle n'en est peut-être pas une. Cela paraît plus négatif que ça ne l'est. Une opportunité qui résiste à des contre-questions sérieuses n'en devient que plus intéressante. Et une idée qui s'effondre pendant cet exercice coûte bien moins cher qu'une idée qui s'effondre après des mois de développement, de discussions avec des fournisseurs et d'attentes internes.

Parfois, la question change complètement en cours de route. On part de l'hypothèse qu'une seule plateforme intégrée est nécessaire, et on découvre que deux systèmes spécialisés fonctionnent mieux ensemble. Ou l'on lit chez un fournisseur le nom d'une fonctionnalité qui semble correspondre exactement à ce qu'on cherche, et l'on constate, en creusant, qu'elle désigne quelque chose de bien plus limité. Ce ne sont pas des détails : si c'est précisément cette caractéristique qui a motivé le début de la recherche, l'opportunité tient ou tombe avec elle.

C'est pourquoi je ramène les affirmations le plus vite possible à ce qui est démontrable. « Le fournisseur prend cela en charge » dit peu de choses en soi : qui voit quoi, sur quel écran, sur la base de quelles données ? Et le fait qu'il existe une API n'est intéressant que si elle donne accès précisément aux données et aux actions nécessaires. Une liste de fonctionnalités en dit généralement moins qu'elle n'en a l'air.

La même chose vaut pour l'étude de la concurrence. Le fait que cinq acteurs existent déjà ne prouve pas qu'une idée est morte. Et le fait que personne n'offre exactement la même chose ne signifie pas encore qu'on a trouvé une niche — peut-être qu'elle existe parce que personne n'en a besoin, ou parce qu'elle n'est pas viable économiquement. Peut-être qu'il y a réellement de la place. Mais c'est une conclusion, pas un point de départ.

C'est pourquoi le product discovery est, pour moi, une forme de business development. Non pas parce qu'il faudrait vendre quelque chose immédiatement, mais parce qu'on essaie de comprendre les possibilités commerciales avant d'engager des moyens. Où se situe la valeur ? Qui serait prêt à payer pour cela ? Quelle alternative existante faut-il battre, et qu'est-ce qui doit être démontrablement meilleur pour cela ? Qu'est-ce qu'on peut acheter tout fait, et qu'est-ce qu'on doit posséder soi-même ?

L'étape suivante peut alors être un prototype, une discussion avec un fournisseur, une petite validation de marché ou un exercice financier. Ou tout simplement : s'arrêter. Ce dernier point est trop rarement considéré comme un résultat. Je trouve que c'est l'une des issues les plus utiles qui soient. Toutes les opportunités ne méritent pas une roadmap ; certaines méritent un non rapide et bien étayé. D'autres reviennent après recherche sous une forme plus simple, moins chère ou plus intéressante que l'idée d'origine. Et un petit groupe résiste à toutes les contre-questions. C'est avec celles-là que je veux continuer.

Une bonne question produit ne commence donc pas par « comment construit-on cela ? », mais par : quel problème résolvons-nous ici réellement — et que faut-il vérifier avant que ceci ne soit une opportunité ?

Mise à jour — ce que ce dossier a clarifié depuis

Depuis la première version de ce texte, le dossier sous-jacent a avancé. La question large — faut-il construire quelque chose de nouveau pour cela ? — s'est entre-temps considérablement resserrée.

Plusieurs pistes ont été écartées. Pas parce que c'étaient de mauvais systèmes, mais parce que l'élément précis à l'origine de la recherche n'était pas démontrable. Les termes marketing se sont révélés plus élastiques que ce qu'il y avait réellement derrière.

Ce qui reste est une question beaucoup plus concrète : une combinaison de systèmes existants peut-elle livrer ce qui est demandé, sans qu'il faille reconstruire du sur-mesure ?

C'est un meilleur résultat qu'un « go » précoce. Le discovery ne doit pas nécessairement aboutir à un nouveau produit. Construire, acheter, combiner, collaborer ou arrêter sont tous des issues valables, du moment que la décision qui suit est plus petite et mieux étayée que la question de départ.

La question passe alors de « qu'est-ce qui existe au juste ? » à : que doit encore prouver cette piste avant qu'on y consacre du temps et de l'argent ?