Cadrer le MVP : la règle des quatre semaines

Un MVP ne prend pas plusieurs mois. Il ne prend pas non plus plusieurs semaines dans la plupart des cas. Quatre semaines de build, c'est le plafond absolu, réservé aux très gros projets.

Pourquoi ce plafond#

Le temps que tu passes à peaufiner des détails est du temps que tu ne passes pas sur l'acquisition. Et l'acquisition, c'est la seule chose qui te dira si le produit a un marché.

Le piège classique : tu builds pendant trois mois, tu lances, personne ne vient, et tu ne sais pas si c'est le produit ou la distribution. Tu as perdu trois mois et l'information. Si tu builds en trois semaines et que tu passes les neuf suivantes sur l'acquisition, tu auras une réponse.

L'acquisition se prépare en parallèle du build, pas après.

Comment couper#

Le tri se fait en trois piles, pas deux :

• Sans ça le produit n'existe pas. C'est le MVP. Généralement 3 à 5 fonctionnalités.
• Le client le demandera dans le mois. Tu l'écris, tu ne le construis pas.
• C'est une idée que j'aime bien. Tu l'écris ailleurs et tu l'oublies.

Quelques questions qui font mal et qui aident :

• Est-ce qu'un client paierait sans cette fonctionnalité ? Si oui, dehors.
• Est-ce que je peux la faire à la main pendant les premiers mois ? Si oui, dehors.
• Est-ce que c'est un réglage que je pourrais mettre en dur pour l'instant ? Si oui, en dur.

Ce qui n'est jamais dans un MVP#

Un back-office d'administration complet, un système de rôles et permissions granulaire, un onboarding en dix étapes, un dashboard analytique, un mode sombre, une API publique, des intégrations.

Ce qui y est toujours#

L'authentification, le parcours qui résout le problème, le paiement. Point.