Minimum Worthy Product

Alors que je reconstruis les surfaces publiques de ResumeGeni, je tombe constamment sur la même ligne inconfortable. La version qui fonctionne techniquement n’est pas toujours celle que je placerai devant un demandeur d’emploi. Le parser tourne. La sortie se charge. Le flux se termine. Et pourtant, quelque chose dans l’expérience dépense la confiance au lieu de la mériter. Je m’y attarde une heure, je reconstruis la surface, et la sensation disparaît, mais l’horloge ne s’arrête pas.

La tension est l’essai même. Deux forces s’opposent : livrer suffisamment tôt pour mettre le produit dans le monde, et refuser de livrer un produit qui dépense la confiance de l’utilisateur. La plupart des bâtisseurs résolvent la tension en choisissant un camp et en le défendant. La culture MVP choisit la vitesse. Le perfectionnisme choisit le polissage. Les deux réponses échouent, parce que la tension est précisément le sujet.

Minimum Worthy Product est une norme différente — livrez le plus petit produit qui mérite la confiance, et non le plus petit produit que vous pouvez défendre comme fonctionnel. Worthy est le plancher, pas le plafond. Minimum est une contrainte de portée, pas une remise sur la qualité. Le bâtisseur MWP coupe les fonctionnalités jusqu’à ce que le produit puisse être livré et tient chaque surface restante à un niveau que l’utilisateur peut ressentir. Le bâtisseur MVP fait trop souvent l’inverse : il coupe la qualité pour protéger la portée. La substitution est ce que les utilisateurs ressentent dans les données.

TL;DR

MVP devait être un outil d’apprentissage : le plus petit artefact qui teste une véritable hypothèse avec de vrais utilisateurs. La version dégradée est devenue la permission de livrer un travail médiocre. Minimum Worthy Product restaure la contrainte manquante. Validez à moindre coût, puis construisez le plus petit produit qui mérite la confiance. Minimum coupe la portée. Worthy maintient la surface restante à un niveau que l’utilisateur peut ressentir.

---

Ce que MVP a bien compris

L’idée originale du MVP ne donnait pas la permission de livrer un travail médiocre. Elle donnait aux fondateurs un moyen d’arrêter de passer des mois à construire la mauvaise chose.¹

Eric Ries a écrit The Lean Startup pour répondre à un mode d’échec spécifique : des ingénieurs construisant des produits élaborés pour des marchés qui n’existaient pas. Le MVP était un instrument d’apprentissage. Vous construisiez le plus petit artefact capable de tester une hypothèse spécifique avec de vrais utilisateurs, vous lanciez l’expérience, vous mesuriez ce qui se passait et vous mettiez à jour votre compréhension quant à savoir si l’hypothèse survivait au contact de la réalité. Le « minimum » dans MVP signifiait un effondrement de la portée au service de l’apprentissage, pas un effondrement de la qualité au service de la livraison.

Le cadrage original tient toujours. Je l’utilise. Ma séquence de validation de startup (problème, solution, canal, revenu, échelle) est en aval de Ries. L’argument en faveur du test des hypothèses peu coûteuses à valider avant d’investir dans le code est le même que celui en faveur du MWP en aval de la validation : l’instrument de chaque étape doit correspondre à son étape. Les pages d’atterrissage et les entretiens sont des MVPs pour la désirabilité. Les prototypes et les spikes sont des MVPs pour la faisabilité. MWP est la norme que vous appliquez lorsque les preuves de validation sont déjà entre vos mains et que vous construisez la première chose réelle à laquelle de vrais utilisateurs feront confiance.

Je ne plaide donc pas contre MVP. Je plaide contre ce que MVP est devenu en pratique.

Là où la culture MVP s’est ramollie

Quelque part en chemin, « apprendre vite » est devenu « livrer n’importe quoi », et la substitution a causé de réels dommages.

Trois traductions ont brisé l’idée originale :

1. « Si vous n’êtes pas embarrassé par la première version de votre produit, vous l’avez lancée trop tard » (la formule de Reid Hoffman⁴) est devenue la permission d’être embarrassé par l’artisanat, et non par la portée. L’affirmation originale concerne le nombre de fonctionnalités : livrez si peu de fonctionnalités que votre futur vous sera embarrassé par le peu que faisait le produit. La version dégradée concerne l’exécution : livrez un produit si rugueux que votre futur vous sera embarrassé par son apparence et son ressenti. Ce ne sont pas les mêmes phrases.

2. « Livrer vite » a remplacé « apprendre vite » comme résultat mesurable. L’apprentissage est un processus lent et agaçant qui produit une intuition qualitative. La livraison est un processus rapide et lisible qui produit un artefact daté. Quand on ne peut plus distinguer les deux, l’artefact gagne par défaut. Les équipes livrent chaque semaine et arrêtent complètement d’apprendre, parce que personne ne mesure ce qu’elles ont appris.

3. Le modèle du capital-risque (lever, croître, sortir) récompense la livraison de quoi que ce soit plutôt que la livraison correcte. Si votre travail consiste à démontrer une dynamique pour le prochain chèque, un produit édulcoré franchit au moins la barre du « nous avons livré ». Un produit digne mais retardé ressemble de l’extérieur à une équipe à l’arrêt. Le gradient d’incitation pointe vers le bas.

Aucune de ces dégradations n’est la faute du MVP tel qu’il a été écrit à l’origine. Ce sont les avatars de MVP dans la bouche de ceux qui avaient besoin d’une justification pour livrer faiblement.

Les utilisateurs ressentent le résultat. Vous le ressentez dans les données. L’onboarding se termine mais la deuxième session n’arrive jamais. Les utilisateurs ouvrent l’e-mail d’inscription et ne cliquent jamais sur le lien. Les tickets de support se regroupent autour de tâches que le produit prétend gérer. La courbe de churn décroît vers zéro au lieu de s’aplatir vers un noyau. Ces résultats ne sont pas des cas marginaux. Ils sont le coût central du fait de construire selon une norme à laquelle l’utilisateur ne peut pas croire.

Minimum ne veut pas dire inachevé

Minimum est une contrainte de portée, pas une remise sur la qualité.

Opérationnellement : définissez l’utilisateur. Définissez le seul résultat que le produit prétend livrer. Supprimez toutes les fonctionnalités non requises pour ce résultat. Puis tenez la surface restante à la barre de qualité complète. Minimum coupe la portée jusqu’à ce que le produit puisse être livré. Minimum ne coupe pas la norme pour que le produit puisse être livré plus tôt.

Les deux normes se tiennent côte à côte :

Dimension	MVP (en pratique)	MWP
Objectif	Livrer quelque chose pour prouver le mouvement	Livrer quelque chose qui mérite la confiance de l’utilisateur
Portée	Plus petit artefact défendable comme fonctionnel	Plus petite surface qui livre la promesse validée
Barre de qualité	Fonctionne assez bien pour tourner	La barre que l’utilisateur peut ressentir
Règle d’arrêt	« Nous avons livré »	Les deux tests passent ; après trois reconstructions ratées, reconstruire le brief
Signal de succès	Date sur le changelog	Cinq proxys de confiance : second-success, ratio J30/J1, forme de cohorte, recommandation organique, friction-qualité
Mode d’échec	Une mauvaise première impression brûle la confiance utilisateur	Le raffinement devient une cachette

Exemple concret. La promesse de ResumeGeni est un CV prêt pour les ATS qui passe proprement par les systèmes de suivi des candidatures et donne au demandeur d’emploi une vraie chance d’atteindre le responsable du recrutement. La version minimale de la promesse peut exclure :

• Les modèles personnalisés
• La collaboration en équipe
• Les tableaux de bord d’analytics
• Les intégrations avec LinkedIn, Indeed ou les sites d’emploi
• L’historique des versions
• Les formats d’export au-delà d’un seul

Ce que la version minimale ne peut pas exclure : un parsing précis du CV source, une évaluation honnête des lacunes, des réécritures concrètes qui correspondent réellement à la description de poste, un export qui s’ouvre proprement dans Word, et un parcours qui fait sentir au demandeur d’emploi qu’il est en sécurité. Vous pouvez livrer sans modèles. Vous ne pouvez pas livrer avec des conseils vagues, des exports cassés, ou un texte qui fait sentir à un utilisateur vulnérable que le produit le traite comme un pigeon.

Minimum est un couteau appliqué au backlog produit. Worthy est un couteau appliqué à la surface qui reste.

Worthy est le plancher

Un produit digne n’a pas à contenir tout ce que vous imaginez. Tout ce qu’il contient doit respecter l’utilisateur.

Worthy au sens opérationnel signifie que le produit résout le problème validé suffisamment bien pour que l’utilisateur emporte sa confiance dans l’interaction suivante. Il voit ce que vous étiez en train de construire et il croit que la suite va arriver. La première session cesse d’être une épreuve à endurer et devient une poignée de main qui ouvre la porte à la deuxième. Les produits dignes accumulent la confiance. Les produits à moitié dignes la dépensent.

Vous ne pouvez pas feindre la confiance. Les produits que les utilisateurs connaissent déjà façonnent ce qu’ils attendent du vôtre.⁵ Quand votre produit se situe en dessous de ces attentes (boutons qui ne répondent pas, texte qui tergiverse, parcours qui les abandonnent à mi-chemin), les utilisateurs enregistrent l’écart avant même de l’articuler. Ils partent, ils ne reviennent pas, et aucun e-mail de rétention ne sauvera la session qu’ils ont déjà classée.

La question est-ce digne ? n’est pas une question de goût. C’est une question de confiance. La réponse de l’utilisateur apparaît sous forme de comportement.

La validation vient d’abord, la dignité ensuite

L’objection la plus forte au MWP est que les utilisateurs déterminent la dignité par contact, et non par la conviction du créateur. Exact. MWP ne remplace pas le jugement de l’utilisateur. MWP vous empêche de brûler la confiance validée avant que les premiers vrais utilisateurs n’aient l’occasion de juger.

Le contact utilisateur appartient à la validation. Avant de construire, vous testez si le problème est réel, si votre solution proposée y répond, si vous pouvez atteindre les utilisateurs et s’ils paieront. Les preuves proviennent de pages d’atterrissage, d’entretiens, de tests concierges, de prototypes et de listes d’attente. J’ai écrit sur la séquence en détail. Une hypothèse qui survit à l’épreuve a gagné le droit d’être construite.

MWP commence après la validation. La validation demande si quelqu’un veut la promesse. MWP demande si la surface livrée mérite la confiance que la validation a déjà gagnée. Les données de rétention, de recommandation et de friction-qualité décident si le jugement a tenu.

Sauter la validation et appeler le résultat MWP produit une belle réponse à une question que personne n’a posée. Sauter MWP et appeler le résultat « lean » produit un produit édulcoré qui coûte la confiance que la validation avait déjà gagnée.

La bonne séquence : validez à moindre coût avec de vrais utilisateurs, puis construisez le plus petit produit digne pour la promesse validée. Faites les deux. N’en sautez aucun.

Les deux tests : Jiro et Steve

Un produit doit passer deux tests différents avant que je ne le considère comme fini.

Le test Jiro demande si le travail est correct. Preuve que le produit fonctionne. Le produit gère ses cas limites. Les détails invisibles tiennent. Les affirmations citent des preuves concrètes. Pas de tergiversation ; je crois n’est pas une preuve. Le test Jiro distingue l’artisanat de l’aspiration. J’ai écrit sur la philosophie de qualité Jiro telle que la discipline s’applique aux agents IA ; la même discipline s’applique à chaque surface produit. Le Evidence Gate est la façon dont j’opérationnalise le test dans les rapports de code.

Le test Steve demande si le travail mérite d’exister. Point de vue visible. Cohérence du produit dans son ensemble. La surface préserve la dignité de l’utilisateur. Un mécanisme d’enchantement ou de clarté que le lecteur peut identifier, et non un vague geste de la main. Le test Steve distingue le produit de l’inventaire. Une chose livrée n’est pas automatiquement une chose digne. L’argumentation complète en faveur du goût comme système technique vit dans un essai séparé ; pour ce billet, la définition opérationnelle ci-dessus porte le poids.

Les deux tests doivent passer. Si Jiro échoue, arrêtez et corrigez. Si Steve échoue, reconstruisez. Si les deux échouent, le problème vit en amont, dans le brief.

La question opérante quand le jugement est incertain est la plus simple de la pile : signerais-je mon nom à cela sans broncher ? Si la réponse est non, le travail n’est pas encore digne.

La preuve sous vos pieds : blakecrosley.com

La page que vous lisez a commencé comme une petite expérience dans ma transition sans chemin. C’est aussi une partie de l’argument.

Il n’y a pas de React. Il n’y a pas de Tailwind. Il n’y a pas de webpack, pas de Vite, pas de bundler, pas d’étape de build. FastAPI sert tout le site directement : HTMX, Alpine.js, Jinja2, et du CSS pur, rien entre les deux. Sur le build du 17 avril 2026, le transfert initial de la page atterrit à 45 à 60 Ko et Lighthouse rapporte 100 sur 100 en performance, accessibilité, bonnes pratiques et SEO.³ Le site fonctionne en dix langues, livre du nouveau contenu de guide et de blog de bout en bout en un seul git push, et ne porte aucun node_modules/ nulle part dans le dépôt.

La version MVP du site aurait suivi le conseil par défaut de 2026 — Next.js, Tailwind, Vercel. Elle aurait été livrée en un week-end. Elle aurait été correcte. Vous auriez atterri ici, la page se serait chargée dans un délai respectable. La différence n’aurait pas été dans la capacité. La différence aurait été dans le goût. J’ai écrit sur comment un score Lighthouse parfait se construit réellement ; la version courte est que chaque Ko de payload que le lecteur ne télécharge pas est une forme de respect.

La version MWP a pris plus de temps. La version MWP a exigé d’écrire les motifs HTMX à partir de zéro, d’ajuster la typographie à la main, d’auto-héberger les polices, de faire passer le pipeline i18n par Cloudflare D1 et de traiter l’absence d’outil de build comme une fonctionnalité. La version MWP n’est pas techniquement plus capable que la pile par défaut. La version MWP est plus intentionnelle. L’intention apparaît sous la forme de moins de coutures que le lecteur peut remarquer.

Artisanat invisible. Le lecteur ne voit pas les décisions. Le lecteur ressent l’absence de friction. L’absence de friction est le mécanisme.

La preuve face au client : ResumeGeni

ResumeGeni élève la barre, parce que l’utilisateur ne navigue pas. L’utilisateur essaie d’améliorer un document qui peut décider s’il décrochera un entretien.

La validation de ResumeGeni est revenue propre : page d’atterrissage, liste d’attente, publications ciblées sur Reddit et LinkedIn, 340 inscriptions par e-mail en deux semaines, 12 demandes directes demandant quand le produit ouvrirait, et 3 offres spontanées de payer pour un accès anticipé.⁷ La séquence de validation disait de le construire. Construire était la décision facile. Ce à quoi la construction ressemblerait était la décision difficile, et c’est là que MWP a fait le vrai travail.

Deux catégories de coupes. La première catégorie était les fonctionnalités : modèles, collaboration, analytics, des dizaines de variantes d’export, intégrations avec les sites d’emploi. Toutes coupées. Aucune ne fait partie de la promesse.

La deuxième catégorie était la norme que j’étais prêt à tenir pour ce qui restait. La norme ne se coupe pas. Le parser ne peut pas être faible. Les conseils ne peuvent pas être vagues. Les exports ne peuvent pas être cassés. Le texte ne peut pas traiter un utilisateur vulnérable comme une métrique de conversion. Le parcours ne peut pas abandonner quelqu’un en cours de route parce que le chemin heureux était tout ce que j’avais le temps de construire.

La version MVP aurait livré un assistant en dix étapes, une sortie générique, un mur d’abonnement au meilleur moment et une page de feuille de route promettant tout ce qui avait été coupé. Elle aurait été fonctionnelle. Elle aurait peut-être converti quelques utilisateurs une fois. Elle aurait aussi appris à la première cohorte à ne pas faire confiance au produit, et la leçon devient une mauvaise fondation pour un cas d’usage vulnérable.

La version MWP est plus petite que je ne le voudrais. Chaque fonctionnalité que j’ai coupée, je voudrai la récupérer. La barre est que le produit sur lequel les utilisateurs atterrissent les respecte. La fondation est la seule sur laquelle je sais construire.

Ce que les utilisateurs vous disent réellement

Les utilisateurs disent rarement je crois en ce produit maintenant. Mais leur comportement laisse des traces.⁶

Cinq signaux que je surveille, calibrés pour un public de bâtisseurs :

1. Taux de second succès. Le pourcentage d’utilisateurs activés qui reviennent et complètent le résultat principal une seconde fois dans la fenêtre d’usage naturelle. La confiance se construit au second succès, pas au premier. Pour les produits récurrents, je traite un second-succès en dessous de 30 % comme un signal de reconstruction. Pour les produits épisodiques, mesurez le prochain cycle d’usage naturel au lieu de forcer une fenêtre de 30 jours.

2. Rétention au jour 30 par rapport à l’activation au jour 1. Les e-mails de réengagement peuvent fausser la rétention brute. Le ratio non. Pour les produits à usage hebdomadaire ou mensuel, le ratio vous dit si l’activation était de la confiance ou une curiosité ponctuelle. J’utilise en dessous de 0,25 comme avertissement et en dessous de 0,15 comme verdict.

3. Forme de la courbe de rétention par cohorte. Les produits dignes s’aplatissent après la chute initiale. Les produits faibles continuent de décroître. Tracez les courbes ; la forme raconte l’histoire que les moyennes cachent. Si la courbe ne s’aplatit jamais, il n’y a pas de noyau d’utilisateurs qui font réellement confiance au produit.

4. Part de recommandation organique non incitée. Le pourcentage de nouveaux utilisateurs activés arrivant via une recommandation directe, une sortie partagée ou le bouche-à-oreille, pas par des canaux payants, pas par des récompenses de programme de parrainage. Les utilisateurs parlent des produits dignes. Les utilisateurs oublient les produits faibles. Si la catégorie a un moment de partage naturel et que la recommandation organique est encore en dessous de 10 % de l’acquisition de nouveaux utilisateurs, le produit ne mérite pas la recommandation.

5. Taux de friction-qualité. Suivez les remboursements, les rage clicks, les tickets de support, les exports échoués et les corrections manuelles pour 100 utilisateurs activés, par cohorte. Le taux est la douleur que le produit inflige aux utilisateurs qu’il prétend servir. Le taux devrait baisser à mesure que le produit mûrit. Si le taux reste plat ou monte, le problème est le produit, pas le processus de support.

Aucun de ces signaux n’est une métrique de vanité. Chacun est difficile à truquer. Chacun est lié à une véritable expérience utilisateur qui a soit gagné la confiance, soit échoué à le faire. Si vous ne pouvez pas nommer les chiffres d’une cohorte spécifique sur les cinq, vous ne savez pas encore si votre produit est digne.

Quand MVP ou prototype reste le bon mouvement

MWP n’est pas la bonne norme pour chaque artefact.

Trois cas où la logique du MVP ou du prototype reste correcte :

• Avant la validation. Pages d’atterrissage, entretiens, tests concierges, prototypes cliquables. L’objectif est l’apprentissage, pas l’artisanat. Livrez la version laide qui teste l’hypothèse. Livrez-la aujourd’hui. La séquence de validation est le bon manuel ici, pas MWP.

• Spikes de faisabilité. Quand l’inconnue est technique (le modèle peut-il répondre à ce type de requête à la latence dont j’ai besoin ? Le API tient-il la charge ? Le parser fonctionnera-t-il sur la longue traîne d’entrées réelles ?), construisez le plus petit instrument jetable qui répond à la question. N’essayez pas de le rendre digne. Rendez-le véridique.

• Surfaces bêta à effet de réseau. Les places de marché, les produits communautaires et les outils à effet de réseau ont besoin d’une vraie base d’utilisateurs avant que quiconque puisse les juger, donc l’artefact correct est une bêta clairement étiquetée avec une instrumentation par cohorte. Livrer une bêta n’est pas un substitut à la version digne ; livrer une bêta est la seule façon de découvrir ce que digne signifie. Étiquetez la surface honnêtement comme bêta. Ne l’habillez pas en v1.

MWP est pour la première vraie surface produit. Si vous êtes encore en amont de la surface (apprentissage, test, découverte), les bons outils vivent plus en arrière dans la séquence.

Le plafond de reconstruction

Une norme élevée sans règle d’arrêt devient de l’évitement.

La doctrine que j’applique à chaque travail non trivial a un plafond de reconstruction de trois tentatives honnêtes.² Une tentative honnête signifie que vous avez identifié l’axe défaillant, nommé le mouvement correctif spécifique, changé l’approche de manière matérielle et réévalué le travail par rapport aux deux tests. Trois répétitions de la même passe de polissage ne comptent pas comme trois tentatives. Les répétitions comptent comme une seule tentative ratée répétée trois fois.

Après trois reconstructions honnêtes qui n’ont pas réussi à produire un produit digne, le problème n’est pas l’artisanat. Le problème vit en amont, dans le cadrage, la portée, le brief ou l’équipe. Arrêtez de reconstruire la surface et regardez la prémisse. Parfois la promesse était trop grande pour la portée que vous pouvez réalistement tenir au standard. Parfois la validation était plus molle que vous ne le pensiez. Parfois le problème n’est pas du tout un problème de produit.

Le plafond de reconstruction résout deux échecs opposés. Il refuse de bénir le travail médiocre, et il empêche le raffinement de devenir une cachette. La cible n’est pas la perfection. La cible est digne et livré. Pas pur et en attente pour toujours.

Le perfectionnisme est l’artisanat sans courage. Si vous en êtes à la quatrième reconstruction de la même surface, vous avez cessé de fabriquer un produit et avez commencé à utiliser le projet comme un endroit où vous cacher.

Points clés à retenir

Pour les fondateurs et les bâtisseurs solos : - Validez à moindre coût avant tout code. MWP s’applique après que la validation a confirmé l’adéquation au marché. - Coupez les fonctionnalités agressivement. Tenez la surface restante à la barre de qualité complète. - Livrez quand c’est digne. Plafonnez les reconstructions à trois. Faites remonter le brief après cela.

Pour les responsables produit et les PM : - Mesurez les proxys de confiance directement : taux de second succès, ratio de rétention jour-30 sur jour-1, forme de la courbe de cohorte, part de recommandation organique, taux de friction-qualité pour 100 utilisateurs. - Séparez les conversations de portée des conversations de qualité. Les coupes de portée sont négociables. Les coupes de qualité ne le sont pas. - Protégez l’expérience de votre première cohorte. Une première impression dégradée sur des utilisateurs vulnérables coûte des années à récupérer.

Pour les responsables d’ingénierie : - Nommez une porte Jiro et une porte Steve pour chaque surface que vous livrez. Les deux doivent passer. - Budgétisez pour l’artisanat invisible. La différence entre « ça marche » et « digne » vit habituellement dans les détails que personne ne pointe du doigt. - Intégrez un plafond de reconstruction dans votre processus pour que le perfectionnisme cesse de se cacher derrière le raffinement.

Pour les designers : - Le point de vue n’est pas une décoration ; c’est le mécanisme qui rend le produit reconnaissable. - Une surface digne refuse des choses, visiblement. Si l’équipe n’a rien refusé, la portée est mauvaise. - Le test opérant dans l’ambiguïté : signeriez-vous votre nom à la décision sans broncher ?

Pour conclure : livrez quand cela mérite la confiance

La question gouvernante en produit n’est pas est-ce fini ? La question gouvernante est est-ce que cela mérite d’exister ?

Si la réponse est oui, livrez. Si la réponse est « pas encore, mais ce le sera dans les trois reconstructions honnêtes », continuez à travailler. Si la réponse est non, et qu’elle reste non après trois tentatives, reconstruisez le brief, pas la surface.

L’approche est la façon dont je construis chaque produit auquel j’attache mon nom. La mentalité MVP optimise pour les cycles. La mentalité MWP s’accumule en un corpus de travail.

Livrez le plus petit produit que vous pouvez respecter. Ne livrez pas avant cela. N’attendez pas au-delà. Minimum et worthy sont la même instruction, tenue simultanément.

---

FAQ

Qu’est-ce qu’un Minimum Worthy Product ?

Un Minimum Worthy Product est la plus petite version publique d’un produit validé qui mérite la confiance de l’utilisateur plutôt que de la dépenser. Minimum signifie que la portée est coupée à la promesse fondamentale. Worthy signifie que la surface restante atteint la barre de qualité que l’utilisateur peut ressentir. La première chose réelle que de vrais utilisateurs voient doit mériter leur confiance, pas seulement fonctionner.

En quoi MWP diffère-t-il du MVP ?

Un Minimum Viable Product tel qu’il a été écrit à l’origine était un instrument d’apprentissage : le plus petit artefact pour tester une hypothèse spécifique. En pratique, MVP s’est dégradé en permission de livrer un travail médiocre. Un Minimum Worthy Product restaure la contrainte manquante. La validation couvre si quelqu’un veut la chose (un travail pour les MVPs, les pages d’atterrissage et les entretiens). MWP couvre la norme que vous tenez quand vous construisez la première vraie version de ce que la validation a confirmé.

Quand les équipes devraient-elles utiliser un MVP plutôt qu’un MWP ?

Trois cas où la logique du Minimum Viable Product ou du prototype s’applique encore : avant la validation (pages d’atterrissage, entretiens, tests concierges, prototypes cliquables), pendant les spikes de faisabilité (code jetable qui teste la latence ou la qualité), et pour les produits à effet de réseau qui ont besoin d’une bêta étiquetée avec de vrais utilisateurs avant que l’équipe puisse définir « digne ». MWP s’applique à la première vraie surface produit, pas à chaque artefact en amont de celle-ci.

Comment mesurez-vous si un produit est digne ?

À travers cinq proxys comportementaux de confiance, pas des métriques de vanité : taux de second succès (pourcentage d’utilisateurs activés qui complètent le résultat principal une seconde fois), rétention au jour 30 par rapport à l’activation au jour 1 (ratio, pas absolu), forme de la courbe de rétention par cohorte (plate ou décroissante), part de recommandation organique non incitée, et taux de friction-qualité (remboursements, exports échoués, tickets de support pour 100 utilisateurs activés). Un produit digne montre de la force sur les cinq ; un produit faible le montrera sur au moins un, et souvent sur tous.

---

The Worthy Gate

Un outil de décision pour appliquer le cadre à votre propre travail. Parcourez les cinq entrées, puis les trois rails de doctrine. Pas de score, pas de jauge gamifiée. Un verdict qui nomme l’axe et le prochain mouvement.

---

Références