Module 01 · Leçon 1
Un problème, pas une idée
Pourquoi les idées échouent et les problèmes tiennent, comment reconnaître un problème quand vous en voyez un, et l’erreur qui coûte le plus cher avant l’appel de définition.
Vous avez une idée. C’est pour cela que vous êtes ici, et c’est très bien. Mais une idée ne se construit pas. Ce qui se construit, c’est une réponse à un problème, et la première chose que nous allons chercher ensemble, c’est le problème qui se cache derrière votre idée.
Cette distinction n’est pas un jeu de vocabulaire. Elle décide de ce qui sera construit, du temps que cela prendra, et de la probabilité que quelqu’un paie à la fin.
La différence, concrètement
Une idée décrit une solution : « une plateforme qui met en relation des coachs et des sportifs », « une application qui gère les stocks des petits commerces ». Elle est séduisante, facile à raconter, et impossible à vérifier avant de l’avoir construite.
Un problème décrit une situation : « les coachs indépendants passent une heure par semaine à renvoyer les mêmes programmes par messagerie et n’ont aucune idée de qui les a ouverts ». Il est vérifiable immédiatement, en parlant à trois coachs. Il désigne une personne, une fréquence, un coût.
| Une idée | Un problème |
|---|---|
| Décrit ce que le produit fait | Décrit ce que quelqu’un vit aujourd’hui |
| Ne peut être testée qu’une fois construite | Se vérifie en trois conversations |
| Plaît à son auteur | Est reconnu par ceux qui le vivent |
| Grossit naturellement | A des bords |
| Donne un périmètre de quatre pages | Donne un périmètre d’une page |
Pourquoi c’est votre sujet et pas le nôtre
Nous savons construire. Nous ne savons pas, à votre place, quel problème mérite d’être résolu dans votre métier, votre secteur, votre réseau. Vous avez une information que nous n’avons pas : vous savez où ça coince, vous connaissez des gens à qui ça arrive, et vous savez quel mot ils emploient pour en parler.
Notre travail à l’appel de définition sera de transformer ce que vous nous apportez en un périmètre constructible. Plus ce que vous apportez est précis, plus le périmètre est juste. C’est aussi simple que cela.
Comment reconnaître un problème
Un vrai problème coche presque toujours quatre cases. Il se répète, c’est-à-dire qu’il revient chaque semaine ou chaque mois plutôt qu’une fois par an. Il coûte, en temps ou en argent, et la personne qui le vit sait à peu près combien. Il a déjà une solution bricolée, un tableur, un groupe de messagerie, un cahier, un assistant payé pour ça. Et celui qui le vit s’en plaint spontanément, sans qu’on le lui demande.
Le quatrième point est le plus révélateur. Un problème dont personne ne parle jamais est presque toujours un problème que personne n’a.
L’erreur qui coûte le plus cher
Arriver à l’appel de définition avec une liste de fonctionnalités. C’est très courant, c’est compréhensible, et c’est ce qui produit les périmètres les plus mauvais. Une liste de fonctionnalités est une réponse à une question que personne n’a posée : elle enferme la discussion dans une solution avant qu’on ait établi le problème.
Nous saurons quoi faire d’un problème bien décrit. Nous ne saurons pas quoi retirer d’une liste de vingt fonctionnalités, sinon en vous demandant de choisir, sans critère.
Ce que vous faites maintenant
Prenez votre idée et retournez-la. Écrivez la situation qu’elle est censée améliorer, en décrivant ce qui se passe aujourd’hui, sans jamais parler de votre produit. Qui, quand, combien de fois, à quel coût, avec quoi à la place.
Si vous n’y arrivez pas, ce n’est pas grave : c’est exactement ce que les cinq leçons suivantes vont vous faire faire, étape par étape.