Quand arrêter la discovery

La discovery est le meilleur outil du PM. C'est aussi sa meilleure excuse pour ne jamais shipper.

Toute équipe produit qui pratique la discovery a déjà vécu ce moment : les interviews s'enchaînent, les insights s'accumulent, mais personne ne dit "OK, on en sait assez, on y va." Il y a toujours une question de plus à explorer, un segment qu'on n'a pas encore couvert, un prototype à tester. Le cycle continue. Le backlog delivery se vide. Et à un moment, quelqu'un dans l'organisation commence à demander pourquoi rien ne sort.

Le problème n'est jamais de savoir comment faire de la discovery. Teresa Torres, Marty Cagan et des dizaines de frameworks couvrent ça très bien. Le problème, c'est de savoir quand tu en sais assez pour décider.

Cet article propose un cadre de décision pour répondre à cette question. Pas une formule magique. Un ensemble de signaux concrets qui indiquent qu'il est temps de shipper, ou de continuer à creuser.

Réduire le risque, pas chercher la vérité

Le chiffre de 5 interviews souvent cité comme seuil de confiance vient d'une étude Nielsen Norman sur les tests d'usabilité, pas sur la discovery produit.nngroup C'est un raccourci que tout le monde répète sans le questionner. Torres elle-même est claire là-dessus : on ne parlera jamais à assez de clients pour être certain de sa décision.

Ce qu'elle propose à la place est plus intéressant. L'objectif d'une équipe produit n'est pas de trouver la vérité, c'est de réduire le risque à un niveau acceptable pour l'entreprise. Pas plus. La discovery est un outil de mitigation, pas une quête de certitude. Et comme tout outil, il a un point de rendement décroissant.

Karl Weick définit la sagesse comme "l'équilibre entre la confiance dans ce qu'on sait et le doute sur ce qu'on sait." C'est exactement ce que devrait être la discovery : pas un outil pour éliminer le doute, mais un outil pour apprendre à décider avec.

Le cadre de décision

En pratique, "acceptable" reste un concept flou. La discovery devient zone de confort. Un espace où on se sent productif sans prendre de décision. Herbig le formule bien : remplacer le nombre de features livrées par le nombre d'interviews utilisateurs, c'est changer de hamster wheel. Même roue, direction différente.

J'ai vécu ça de l'intérieur. On repensait le dashboard d'un produit B2B, le genre de sujet où chaque stakeholder a sa vision. Après 8 interviews en 3 semaines, le pattern était là : les utilisateurs voulaient voir moins de données, pas plus. Mais l'équipe n'était pas à l'aise avec cette réponse. Trop simple. Alors on a continué à chercher la nuance qui justifierait un dashboard plus riche. On a shippé trois semaines plus tard, quand on a fini par admettre que la réponse ne changerait pas. La discovery n'avait pas duré trop longtemps parce qu'on manquait de signal. Elle avait duré trop longtemps parce que le signal ne nous plaisait pas.

Deux questions suffisent pour sortir de ce flou. Leur croisement donne une matrice qui couvre la grande majorité des cas.

Réversibilité

C'est le framework one-way door / two-way door popularisé par Amazon et systématisé chez Stripe par Shreyas Doshi.shreyasdoshi La première question à se poser : est-ce que tu peux revenir en arrière ?

• Two-way door : la décision est réversible. Un nouveau flow d'onboarding, un changement de wording, un test A/B. Si tu te trompes, tu rollback ou tu itères. Le coût d'erreur est faible, donc le coût de l'inaction (ne pas shipper) dépasse vite le coût d'une mauvaise décision.
• One-way door : la décision est irréversible, ou très difficilement réversible. Une migration de plateforme, un pivot de pricing, une refonte d'architecture core. Le coût d'erreur est élevé, donc chaque effort de recherche supplémentaire se justifie.

Survole pour comparer les caractéristiques.

La majorité des features sur lesquelles les PMs hésitent sont des two-way doors traitées comme des one-way doors. Le contraire est plus dangereux : traiter une vraie one-way door comme un truc qu'on pourra "itérer plus tard".

L'inverse aussi existe. Sur un produit SaaS, on a dû choisir un provider LLM pour automatiser une partie de notre analyse. L'équipe voulait shipper un MVP vite. "On itérera." Sauf que nos clients grands comptes avaient des clauses contractuelles sur le traitement de leurs données. Choisir un provider IA, c'était engager l'entreprise sur un cadre légal qu'on ne pourrait pas défaire en un sprint. One-way door. On a pris 4 semaines pour valider le choix avec le légal et les clients. Sans cette discovery supplémentaire, on aurait passé 6 mois à renégocier des contrats. C'est le cas où ralentir était la bonne décision.

Impact

Une feature qui touche 2% de tes users et le lancement d'un nouveau plan tarifaire n'exigent pas le même niveau de confiance. Pour évaluer l'impact rapidement, trois questions suffisent :

• Reach : combien d'utilisateurs sont touchés directement ?
• Conséquence : si ça rate, quel est le dommage business ? (churn, revenu, réputation, signal de marché)
• Coût de correction : combien de temps et d'effort pour corriger le tir ?

Un changement de couleur sur un bouton CTA touche 100% des utilisateurs, mais la conséquence est mineure et la correction immédiate. Impact faible. Une migration de pricing touche 30% des comptes, mais la conséquence est du churn et la correction prend 6 mois. Impact fort, même si le reach est plus faible.

Si une feature est estimée à un jour de dev, passer une semaine en recherche n'a aucun sens. Lance-la, mesure, itère. Le niveau de discovery doit être proportionnel à l'impact, pas uniforme.

La matrice

En croisant ces deux axes (réversibilité et impact) tu obtiens quatre zones de décision claires.

Les signaux

La matrice se pose avant de commencer : quelle profondeur de discovery pour cette décision ? Les signaux se lisent pendant : est-ce que j'en sais assez maintenant ?

Quand arrêter

Deux signaux suffisent. Si tu les as, tu peux shipper.

Les interviews convergent. Tu entends les mêmes frustrations, les mêmes workarounds, les mêmes mots. L'interview n°8 ne t'apprend rien que la n°4 ne t'avait pas déjà dit. C'est de la saturation. Pas besoin d'un chiffre magique pour la reconnaître.

Tu peux formuler le pari. Si tu es capable de résumer en une phrase ce que tu paries, sur quel segment, et pourquoi, tu en sais assez. Si tu ne peux pas, ce n'est pas plus de discovery qu'il te faut. C'est plus de clarté sur ce que tu cherches.

Trois confirmations secondaires qui renforcent la décision :

• Le coût du prochain test dépasse sa valeur. Torres appelle ça le point d'arrêt naturel : quand l'effort pour tester dépasse ce qu'on apprendrait en construisant directement, ship.evansamek
• L'équipe débat du "comment", plus du "quoi". Quand les conversations passent de "est-ce qu'on devrait faire ça ?" à "comment on fait ça ?", la confiance implicite est là.
• Le contexte business a tranché pour toi. Un concurrent lance une feature similaire, un client enterprise conditionne son renouvellement. La discovery ne sert plus à décider si, mais comment.

Quand continuer

Un signal suffit pour ne pas shipper.

Tu ne peux pas nommer le risque principal. Cagan identifie quatre risques : valeur, usabilité, faisabilité, viabilité business. Si tu ne sais pas lequel est ton risque dominant, tu n'es pas prêt.productboard L'absence de risque nommé n'est pas un signe de sécurité. C'est un signe d'ignorance sur ce qui pourrait mal tourner.

Trois signaux d'alerte complémentaires :

• Les interviews divergent. Pas de pattern, des besoins contradictoires. Soit ta cible est trop large, soit tu n'as pas trouvé le vrai problème.
• Tu confonds conviction et preuve. L'envie de shipper n'est pas un signal de confiance. C'est de l'impatience déguisée en agilité. Shreyas Doshi décrit bien ce piège.
• Tu n'as testé qu'avec des enthousiastes. Ce qui compte, c'est où ton problème se place dans leur stack de priorités. Position 7 sur 10 ? Ta feature ne sera jamais utilisée.opinionx

Ces signaux peuvent se résumer en trois questions rapides :

L'assurance psychologique

Dans mon expérience, la majorité des cycles de discovery trop longs ne sont pas causés par un manque de signal. Ils sont causés par un manque de courage pour décider. Le biais inverse existe et shipper trop vite sur une one-way door coûte cher. Mais le déséquilibre courant penche nettement du côté de la discovery prolongée.

La discovery rassure. Elle donne l'impression de contrôler l'incertitude. Mais la sagesse en produit, c'est l'équilibre entre confiance et doute, pas l'élimination du doute. "Faisons plus de recherche" sonne bien. Ça ne décide rien.

J'ai vu le cas inverse fonctionner. On hésitait sur la refonte d'un moteur de recherche interne. 6 interviews convergeaient, feature réversible, risque principal identifié. L'équipe voulait prototyper avant de développer. Le prototype aurait pris plus longtemps que le dev. On a shippé. En 48h, les données d'usage ont révélé un problème qu'aucune interview n'avait prédit : en production, les utilisateurs ne tapent pas des requêtes propres — ils copient-collent du texte brut depuis leurs emails. La qualité des résultats s'effondrait. Corrigé en quelques jours. Aucun prototype n'aurait capté ça.

Le problème n'est pas le courage ou la lâcheté. C'est l'absence d'outils pour transformer l'inconfort en décision. Trois pratiques qui aident :

• Le pre-mortem inversé. Au lieu de demander "qu'est-ce qui pourrait mal tourner si on shippe ?", demander "qu'est-ce qu'on perd si on ne shippe pas cette semaine ?". Ça force l'équipe à quantifier le coût de l'inaction, pas seulement le coût de l'erreur.
• La deadline de discovery. Fixer une date de décision avant de commencer la recherche. "On décide le 15, quoi qu'on sache." Sans cette contrainte, le scope de la discovery gonfle naturellement — il y a toujours une question de plus.
• "What would we need to believe." Formuler explicitement les hypothèses qui justifient de shipper. Si l'équipe peut les énoncer et qu'aucune n'est manifestement fausse, c'est suffisant. Pas besoin de les prouver.

Le PM qui shippe avec 70% de confiance et corrige en vol apporte plus de valeur que celui qui atteint 95% de confiance trois mois trop tard. La prochaine fois que tu te demandes si tu en sais assez, essaie de compléter cette phrase :

Si tu y arrives, shippe. Si tu n'y arrives pas, le problème n'est pas le volume de recherche. C'est la clarté de ce que tu cherches.