Méthode MoSCoW :80 idées de fonctionnalités, 5 à créer

Vous avez 80 idées de fonctionnalités : 50 des vôtres et 30 de plus suggérées par vos utilisateurs. La méthode MoSCoW (Must have, Should have, Could have, Won't have) réduit ces 80 idées aux 5 fonctionnalités, ou moins, qui testent réellement votre hypothèse. Tout le reste est une distraction, et la plupart relève du Won't have.

En plus de vos 80, les concurrents ont 20 autres fonctionnalités que vous n'avez pas. Vous ne pouvez pas tout construire, et vous ne devriez pas. Voici le cadre pour couper sans pitié : la question-test de chaque catégorie, à quoi ressemblent une bonne et une mauvaise priorisation sur des calendriers réels, et la règle qui vous empêche de construire ce que vous pourriez simplement faire à la main.

Qu'est-ce que la méthode MoSCoW pour un MVP ?

MoSCoW range chaque fonctionnalité dans l'une de quatre catégories, chacune avec une seule question-test. Répondez honnêtement et la liste de 80 éléments s'effondre d'elle-même :

Remarquez ce qui échoue au test du Must have dans cet exemple. Les niveaux de priorité ? Les utilisateurs peuvent réordonner la liste à la main. Les catégories et les tags ? Agréables, pas essentiels. Les tâches récurrentes ? On peut les créer à la main. Une fonctionnalité n'est pas un Must have parce qu'elle est utile : c'est un Must have parce que votre hypothèse est impossible à tester sans elle.

Vous ne construisez pas un produit minimum viable

Vous construisez un produit minimum testable. Ce recadrage change tout, parce qu'il ancre chaque décision de priorisation sur votre hypothèse plutôt que sur votre vision. La vision, c'est pour la version 10. Si vous ne pouvez pas énoncer votre hypothèse en une phrase, arrêtez-vous et réglez d'abord cela : elle découle directement du travail de validation que vous avez fait avant de décider de construire quoi que ce soit.

Et le Won't have est là où vit la discipline. Ce n'est pas un backlog : c'est une liste de fonctionnalités que vous décidez activement de ne pas construire, chacune avec un déclencheur écrit pour la reconsidérer : après 100 utilisateurs, après la validation de la V1, ou si les utilisateurs la demandent cinq fois ou plus. Écrire le déclencheur est ce qui empêche la fonctionnalité de se glisser de nouveau dans le périmètre dès la deuxième semaine.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

La deuxième passe : impact contre effort

MoSCoW vous fait passer de 80 à une présélection. La matrice impact-effort vous amène à cinq. Notez chaque fonctionnalité restante selon deux dimensions, combien elle aide l'utilisateur (1 à 10) et combien de jours elle prend honnêtement à construire, et quatre quadrants apparaissent :

• Quick wins (fort impact, faible effort) : c'est votre MVP.
• Gros projets (fort impact, fort effort) : à faire après la validation, jamais avant.
• Bouche-trous (faible impact, faible effort) : de la finition, seulement s'il reste du temps.
• Pertes de temps (faible impact, fort effort) : à ne jamais construire : le moteur de reporting sur mesure que deux utilisateurs pourraient vouloir, la fonctionnalité d'IA que personne n'a demandée, les permissions complexes pour des cas marginaux.

Méfiez-vous de vos propres chiffres. Les fondateurs sous-estiment systématiquement l'effort et surestiment l'impact : ajoutez donc une marge de 50 % à chaque estimation, contestez chaque note d'impact de 9 sur 10, et gardez le temps de construction total sous quatre semaines.

Le faire à la main avant de le construire

Pour chaque fonctionnalité qui survit, posez une question de plus : puis-je le faire manuellement pour les 10 premiers utilisateurs ? Si oui, ne le construisez pas encore. Envoyez vous-même les notifications par e-mail. Montez le rapport hebdomadaire dans un tableur. Accueillez chaque utilisateur lors d'un appel personnel. Facturez à la main. Importez leur CSV à leur place.

Commencer en manuel permet de lancer plus vite, vous apprend ce dont les utilisateurs ont réellement besoin plutôt que ce qu'ils disent avoir besoin, et crée des relations avec les premiers utilisateurs, qui comptent le plus. Et c'est un test de demande déguisé : si vous n'avez pas envie de faire quelque chose à la main pour 10 utilisateurs, pourquoi le construire pour 1 000 ? N'automatisez que lorsque vous avez fait la tâche manuellement plus de 10 fois, qu'elle prend plus de 30 minutes à chaque fois, que le schéma est constant et que les utilisateurs le demandent explicitement.

À quoi ressemblent une bonne et une mauvaise priorisation

Même idée de gestionnaire de tâches, deux décisions de périmètre. La mauvaise version : tâches récurrentes, sous-tâches, tags et catégories, suivi du temps, partage d'équipe, application mobile, vue calendrier, diagrammes de Gantt : 90 jours de construction. La bonne version : créer une tâche, fixer une échéance, la marquer comme terminée, une vue en liste simple et un résumé quotidien par e-mail envoyé manuellement aux 10 premiers utilisateurs : 14 jours. Livré en deux semaines au lieu de trois mois.

De toute façon, le vrai coût n'est pas celui des fonctionnalités coupées : c'est l'apprentissage perdu. Un CRM pour freelances, ramené d'un plan de huit fonctionnalités sur 120 jours à cinq fonctionnalités (ajouter un contact, ajouter des notes, taguer un statut, recherche simple, export CSV manuel), a été livré en 21 jours, et les utilisateurs ont révélé ce qu'aucune feuille de route n'avait prédit : ils ne voulaient pas du tout de gestion de projet, ils voulaient des rappels de relance. Un créateur de pages d'atterrissage, ramené d'un plan de 60 jours à cinq modèles, du texte modifiable et un formulaire de base, a appris que les utilisateurs voulaient plus de modèles, pas de la personnalisation. Quatre-vingt-dix jours de construction en plus auraient été quatre-vingt-dix jours à construire la mauvaise chose.

Les cinq pièges qui remplissent de nouveau votre périmètre

1. « Mais c'est essentiel à notre vision. » La vision, c'est pour la V10. Qu'est-ce qui est essentiel pour tester l'hypothèse ?
2. « Des utilisateurs l'ont mentionné. » Lesquels ? À quel point est-ce douloureux ? Paieront-ils ? Une personne prête à payer pèse plus que dix suggestions du type « ce serait cool si… ».
3. « Ce ne sont que deux jours de plus. » Deux jours deviennent deux semaines avec le débogage. Coupez ; ajoutez plus tard si le besoin est prouvé.
4. « Les concurrents l'ont. » Ils ont passé des années à le construire. Vous testez, vous ne rivalisez pas.
5. « On ne peut pas lancer sans ça. » Si, vous le pouvez. Quel est le strict minimum ?

Si votre liste finale compte plus de cinq fonctionnalités, vous n'avez pas fini de couper. La meilleure fonctionnalité est celle que vous ne construisez pas : chaque coupe livre plus vite, apprend plus vite, coûte moins cher et se maintient plus facilement. Votre but n'est pas de construire un produit. Votre but est de tester une hypothèse.

Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →

Questions fréquentes

Que signifie MoSCoW ?

Must have, Should have, Could have, Won't have. Chaque catégorie a son test : Must have signifie que l'hypothèse ne peut pas être testée sans elle ; Should have signifie que les premiers utilisateurs utiliseraient quand même le produit sans elle ; Could have signifie que personne ne cesserait d'utiliser le produit si elle manquait ; Won't have signifie qu'elle détourne de la valeur centrale et qu'elle est explicitement coupée.

Combien de fonctionnalités un MVP doit-il avoir ?

Cinq ou moins. Si votre liste est plus longue, vous n'avez pas fini de couper. Gardez le temps de construction total sous quatre semaines, ajoutez une marge de 50 % à chaque estimation d'effort et contestez chaque « must have » : la plupart des fonctionnalités relèvent du Won't have.

Quelle est la différence entre Must have et Should have ?

Un Must have est une fonctionnalité sans laquelle vous ne pouvez pas tester votre hypothèse centrale : retirez-la et l'expérience est morte. Un Should have améliore nettement l'expérience, mais les premiers utilisateurs utiliseraient quand même le produit sans elle, donc elle attend la validation de la V1.

Quand faut-il automatiser un processus manuel ?

Seulement lorsque vous l'avez fait manuellement plus de 10 fois, qu'il prend plus de 30 minutes à chaque fois, que le schéma est clair et constant, et que les utilisateurs demandent explicitement l'automatisation. D'ici là, le travail manuel coûte moins cher que le code, et il vous apprend ce dont les utilisateurs ont réellement besoin.