Abandonner une idée de fonctionnalité avant qu'elle coûte

Pour abandonner une idée de fonctionnalité, testez à bas coût son hypothèse la plus risquée, décidez d'avance quel résultat veut dire stop, puis arrêtez-vous vraiment. Notez ce que vous avez appris pour que l'idée ne se glisse pas de nouveau dans six mois. Chaque idée abandonnée vous rend des semaines de soirées.

Comment abandonner une idée de fonctionnalité

Personne ne va vous organiser une fête pour la fonctionnalité que vous n'avez pas construite.

C'est le problème. Quand vous livrez, il y a un journal des modifications, un tweet, une petite dose de fierté. Quand vous tuez une idée, il y a le silence. Vous êtes seul, donc personne avec qui fêter, et la décision n'est consignée nulle part. En quelques mois, la découverte paraît improductive à côté de toutes ces livraisons visibles.

Elle ne l'est pas. Tuer la bonne idée est souvent la chose la plus précieuse que produit votre semaine. Elle vous rend des semaines de soirées, et les soirées sont le seul budget qu'une entreprise d'une personne ne peut pas remplir.

Apprenez donc à le faire volontairement. Voici la méthode.

Pourquoi les idées sont si difficiles à abandonner

Parce que vous l'avez déjà construite dans votre tête.

Vous voyez l'écran. Vous avez nommé le bouton. Vous savez quels clients vont l'adorer. Quand vous « évaluez » l'idée, vous ne jugez plus un pari. Vous défendez un plan.

Et l'IA a aggravé les choses. Avant, construire la mauvaise chose prenait des mois et un développeur, donc le coût vous forçait à la prudence. Maintenant, ça prend un week-end. La tentation est de sauter la question et d'aller droit à une belle réponse. Le coût ne vous protège plus. Vous devez vous protéger volontairement.

Une fonctionnalité abandonnée en un après-midi, c'est un week-end conservé.

Guide gratuit · 21 pagesContinuez à découvrir. Continuez à construire.Comment continuer à découvrir tout en construisant, seul, sans arrêter ni l'un ni l'autre.Recevoir le guide gratuit →

Étape un : retirez la solution, trouvez l'hypothèse

Une idée arrive sous forme de fonctionnalité. « Ajouter un tableau de bord. » « Construire le nouvel onboarding. » C'est une solution, et les solutions ne se testent pas. Les hypothèses, si.

Retournez donc la question. Demandez ce qui doit être vrai pour que ça marche :

• Les gens ont réellement le problème.
• Ils changeront leur comportement pour utiliser la solution.
• Ils la comprendront.
• Ils paieront, ou au moins la valoriseront assez pour que cela compte.

Classez-les selon celle qui ferait le plus mal si elle était fausse. Puis attaquez celle-là. Pas la confortable. La plupart d'entre nous testent si la chose est utilisable, parce que l'utilisable est mesurable et agréable. Savoir si quelqu'un s'en soucie est l'hypothèse qui tue réellement les idées, et elle reste souvent intacte jusqu'au lancement. Notre article sur trouver l'hypothèse la plus risquée montre comment la repérer.

Étape deux : décidez à quoi ressemble « mort » avant de tester

C'est l'étape qui rend le reste honnête.

Avant de lancer le test, complétez cette phrase par écrit : « Si je vois ___, j'abandonne. »

Puis posez la vraie question. Si ça revient négatif, vais-je vraiment m'arrêter ?

Si la réponse honnête est non, ne faites pas le test. Construisez la chose. Au moins, c'est honnête. Un test que vous ignoreriez est pire que pas de test : il vous coûte une soirée et fabrique une fausse confiance.

Si la réponse est oui, vous avez un vrai interrupteur d'arrêt. Choisissez maintenant le test le moins cher capable de vous faire bouger. Une conversation. Une page avec un prix. Un prototype rudimentaire. Le faire à la main pour une personne. Ou regarder des données que vous avez déjà. L'article sur les tests peu coûteux passe en revue les options.

Étape trois : lisez le résultat en sceptique

Quand le résultat est mauvais, votre cerveau commence à marchander. « Ils n'ont pas compris la question. » « Mauvaise semaine. » « Avec un meilleur design, peut-être. »

Parfois c'est vrai. La plupart du temps, c'est la partie de vous qui voulait construire, en train de faire appel.

Utilisez ce tableau pour rester honnête.

Regardez encore la deuxième ligne. Si vous avez d'abord écrit le seuil, cet argument se termine en une ligne. C'est toute la valeur de l'écrire.

Étape quatre : rédigez la nécrologie quand vous abandonnez une idée de fonctionnalité

Quatre lignes. C'est tout.

1. Ce que j'ai demandé ou supposé.
2. Ce que j'ai fait pour le tester.
3. Ce que j'ai trouvé.
4. Ce que j'ai décidé, et pourquoi.

Gardez-la quelque part où vous la retrouverez dans six mois. Pas dans votre tête. Pas dans une discussion que vous ne rouvrirez jamais.

Il y a deux raisons. D'abord, cela protège votre travail de découverte de votre propre accusation qu'il ne produit rien. Une liste d'idées abandonnées est un résultat. Elle prouve que le filtre fonctionne. Ensuite, cela empêche la même idée de revenir. Sans trace, la même suggestion reviendra dans six mois, paraîtra neuve, et vous coûtera le même test.

Avant de commencer quelque chose qui vous paraît familier, consultez la trace. Elle est peut-être déjà morte.

Évaluation gratuiteÀ quel point êtes-vous piégé ?Faites l'Indice d'Asphyxie Corporate, l'évaluation gratuite pour savoir si vous êtes prêt à devenir solopreneur.Faire l'évaluation →

Étape cinq : refusez le zombie

L'idée que vous avez tuée essaiera de revenir sous un autre costume.

Elle reviendra en version « lite ». En expérience. En quelque chose qu'un client a évoqué en passant. Quand elle se présente, passez-la au même filtre que toute nouveauté : quelle est l'hypothèse, qu'est-ce qui me ferait l'abandonner, que disait la trace ?

Si de nouvelles preuves sont apparues, tant mieux. Rouvrez-la. Si rien n'a changé sauf votre humeur, elle reste morte.

Une remarque sur les clients. Une seule demande est un point de donnée, pas un mandat. Voyez-y une raison d'interroger sur leur comportement passé, avec les habitudes de parler à vos clients sans les influencer. Ne la traitez pas comme un cahier des charges.

Ce que vous gagnez en abandonnant une idée de fonctionnalité

Disons que vous vendez seul un service packagé. Une idée de fonctionnalité tombe un mardi. Elle prendrait la plus grande partie d'un mois de soirées à construire. Vous passez deux conversations et un coup d'œil aux données que vous avez déjà, et l'idée échoue au seuil que vous aviez fixé. Combien ça a coûté ? Une soirée ou deux. Qu'est-ce que ça a rendu ? Un mois. Un mois que vous pouvez maintenant consacrer à quelque chose qui a de meilleures preuves derrière. Chaque idée tuée pour deux conversations, c'est un mois de soirées redirigé. C'est l'économie de toute la pratique. Construire est de loin la manière la plus chère de tester une hypothèse. La découverte existe pour répondre à bas prix à ce à quoi vous répondriez autrement en soirées. Un abandon est la preuve la plus nette que ça a marché.

Il y a aussi un bénéfice plus discret. Quand on travaille seul, l'incertitude n'a nulle part où aller. Soit vous construisez la chose dont vous doutez, soit vous vous disputez avec vous-même à onze heures du soir et vous perdez. Un processus d'abandon vous donne une troisième option : voilà une vraie question, voilà le test pas cher, je saurai d'ici vendredi. Une boucle d'angoisse devient une question avec une date.

Guide gratuit · 21 pagesContinuez à découvrir. Continuez à construire.Comment continuer à découvrir tout en construisant, seul, sans arrêter ni l'un ni l'autre.Recevoir le guide gratuit →

Comment savoir si vous abandonnez assez

Voici un contrôle brutal. Repensez à vos derniers mois de découverte. Combien de décisions de ne pas construire a-t-elle produites ?

Si la réponse est aucune, la découverte n'est pas un filtre. C'est un processus d'approbation. Votre liste de construction est alimentée sans examen, avec quelques réunions en plus. Cela arrive surtout quand vous mettez des fonctionnalités décidées d'avance dans la voie de découverte : valider une solution déjà choisie produit invariablement la confirmation que vous étiez venu chercher.

Une voie saine abandonne des choses. Pas tout, et pas par habitude. Mais régulièrement, et visiblement. Comptez. Mettez les idées abandonnées à côté des idées livrées et voyez quelle liste est la plus longue. Pour savoir si votre idée franchit un jour le seuil, l'article sur la validation la traite de l'autre côté.

Évaluation gratuiteÀ quel point êtes-vous piégé ?Faites l'Indice d'Asphyxie Corporate, l'évaluation gratuite pour savoir si vous êtes prêt à devenir solopreneur.Faire l'évaluation →

Questions fréquentes

Comment savoir qu'une idée vaut d'être abandonnée plutôt que testée davantage ?

Si l'hypothèse la plus risquée a été testée et que le résultat est sous le seuil écrit d'avance, abandonnez. Si vous n'avez jamais testé l'hypothèse dangereuse, seulement la confortable, testez à nouveau avant de décider dans un sens ou dans l'autre.

Et si un client demande la fonctionnalité ?

Voyez-y le point de départ d'une conversation, pas une consigne. Demandez ce qu'il fait aujourd'hui face au problème, la dernière fois qu'il l'a rencontré et ce qu'il a essayé. Le comportement passé est une preuve. Une demande est une prédiction.

Dois-je noter les idées auxquelles je n'ai pensé qu'une minute ?

Notez celles que vous avez testées ou pesées sérieusement. Quatre lignes suffisent. Le but est que personne, y compris vous dans le futur, ne perde une autre soirée à réapprendre la même chose.

Puis-je y revenir après avoir décidé d'abandonner une idée de fonctionnalité ?

Oui, si les preuves ont changé. La trace vous dit ce que vous supposiez et pourquoi vous vous êtes arrêté, pour voir si quelque chose est réellement différent. Si seul votre enthousiasme a changé, laissez-la tranquille.

Abandonner une idée de fonctionnalité me rend-il moins ambitieux ?

Non. Cela oriente vos soirées limitées vers les idées qui ont les meilleures preuves derrière. Construire magnifiquement la mauvaise chose est le choix sans ambition, parce que cela ressemble à du progrès sans en être.

La méthode complète, avec les listes de contrôle, est dans Le Playbook du dual track agile, un playbook gratuit de 21 pages.