Une solution utile n'a pas besoin de résoudre tout le problème dès le premier jour.
Lorsqu'une idée commence à prendre forme, il est tentant d'ajouter immédiatement des fonctions, des options et des automatisations.
Chaque ajout peut sembler raisonnable.
Mais ensemble, ils peuvent transformer une petite solution testable en un projet long, coûteux et difficile à modifier.
Avant de construire davantage, posez-vous donc une question simple :
Quelle est la plus petite chose qui doit réellement fonctionner pour apporter une valeur utile ?
Commencez par décrire ce que la personne doit pouvoir accomplir.
Par exemple, au lieu de penser :
« Il me faut un tableau de bord, des notifications, des comptes utilisateurs et plusieurs automatisations. »
essayez :
« La personne doit pouvoir voir clairement ce qu'elle doit faire ensuite. »
Ou, au lieu de :
« Je dois construire une application complète de comparaison. »
essayez :
« La personne doit pouvoir comparer deux options suffisamment bien pour prendre une décision. »
Cette différence est importante.
Une fonctionnalité est un moyen. Le résultat utile est ce que vous cherchez réellement à produire.
Prenez toutes les fonctionnalités ou étapes que vous envisagez et classez-les :
INDISPENSABLE
Sans cet élément, la solution ne peut pas produire le résultat principal.
UTILE PLUS TARD
L'élément améliore la solution, mais le premier résultat utile reste possible sans lui.
PAS ENCORE JUSTIFIÉ
L'élément repose surtout sur une hypothèse, une préférence ou un besoin futur qui n'a pas encore été observé.
Si vous hésitez entre deux catégories, demandez :
« Que se passe-t-il concrètement si je ne construis pas cela maintenant ? »
Si le résultat principal reste possible, l'élément n'est probablement pas indispensable à la première version.
Avant d'automatiser une tâche, demandez-vous si vous pouvez produire le même résultat manuellement pour quelques utilisateurs.
Par exemple :
comparer des informations dans un tableur avant de construire un outil de comparaison ;
envoyer manuellement un résultat avant de développer un système de notifications ;
accompagner personnellement quelques utilisateurs avant de construire un processus d'onboarding complet ;
traiter quelques demandes à la main avant d'automatiser leur traitement.
Ce n'est pas toujours une solution durable.
Mais au début, cela peut vous apprendre quelles étapes sont réellement nécessaires, lesquelles sont inutiles et où se trouve la vraie difficulté.
N'automatisez pas encore un processus que vous ne comprenez pas suffisamment.
Une petite première version n'est pas seulement faite pour fonctionner.
Elle doit également vous aider à apprendre quelque chose.
Avant de la construire, complétez cette phrase :
« Après avoir testé cette version, je veux savoir si… »
Par exemple :
les utilisateurs comprennent comment obtenir le résultat ;
le résultat leur fait réellement gagner du temps ;
ils reviennent utiliser la solution une deuxième fois ;
ils sont prêts à remplacer leur méthode actuelle ;
ils acceptent de consacrer du temps ou de l'argent à cette solution.
Si vous ne savez pas ce que vous cherchez à apprendre, vous risquez de construire davantage sans savoir si cela vous rapproche réellement d'une meilleure solution.
Définissez d'abord la question. Construisez ensuite juste assez pour obtenir une réponse.
Une fois la première version utilisée par de vraies personnes, observez ce qui se passe.
Demandez-vous :
Où les utilisateurs bloquent-ils ?
Qu'est-ce qu'ils n'utilisent pas ?
Que font-ils d'une manière que vous n'aviez pas prévue ?
Qu'est-ce qui manque réellement pour obtenir le résultat principal ?
Quelles demandes reviennent plusieurs fois ?
Ne transformez pas automatiquement chaque demande en nouvelle fonctionnalité.
Cherchez d'abord à comprendre pourquoi elle est demandée.
Parfois, une nouvelle fonction est nécessaire. Parfois, le vrai problème vient d'une explication insuffisante, d'une étape inutile ou d'une mauvaise compréhension du besoin.
Ajoutez ce que l'usage justifie, pas tout ce que vous pouvez imaginer.
Pour chaque fonctionnalité, automatisation ou étape supplémentaire, posez-vous quatre questions :
Est-elle nécessaire pour produire le résultat principal ?
Répond-elle à un besoin réellement observé ?
Que se passe-t-il si nous ne la construisons pas maintenant ?
Pouvons-nous apprendre ce dont nous avons besoin sans la construire ?
Classez ensuite l'élément dans l'une de ces trois catégories :
MAINTENANT
Sans cet élément, la personne ne peut pas obtenir le résultat principal ou vous ne pouvez pas tester l'hypothèse essentielle.
Construisez-le aussi simplement que possible.
PLUS TARD
L'élément peut apporter de la valeur, mais la première version peut fonctionner et vous permettre d'apprendre sans lui.
Notez-le, mais ne le laissez pas ralentir ce que vous devez vérifier maintenant.
PEUT-ÊTRE JAMAIS
L'élément semble intéressant, mais aucun besoin réel ne le justifie encore.
Ne le construisez pas simplement parce qu'il pourrait être utile un jour.
Une liste de fonctionnalités n'est pas une obligation. C'est une collection d'hypothèses qui doivent mériter leur place.
Quel est le résultat principal que la première version doit produire ?
Quels éléments sont réellement indispensables pour obtenir ce résultat ?
Que pouvez-vous encore faire manuellement ?
Qu'est-ce que cette version doit vous permettre d'apprendre ?
Quel comportement réel déterminera ce que vous construirez ensuite ?
Si vous ne pouvez pas encore répondre, ajouter des fonctionnalités n'est probablement pas la prochaine étape. Simplifiez d'abord.
L'IA peut être utile pour remettre en question une liste de fonctionnalités et rechercher une version plus petite.
Mais donnez-lui un objectif clair : ne pas améliorer votre liste, mais essayer de la réduire sans perdre le résultat principal.
Je veux construire la plus petite solution utile pour tester un besoin réel.
Le problème que j'essaie de résoudre :
[PROBLÈME]
La personne concernée :
[UTILISATEUR]
Le résultat principal qu'elle doit pouvoir obtenir :
[RÉSULTAT]
Voici les fonctionnalités, étapes ou automatisations que j'envisage :
[LISTE]
Analyse cette liste de manière critique.
Pour chaque élément, indique :
s'il est indispensable pour produire le résultat principal ;
quel besoin observé le justifie ;
ce qui se passerait s'il n'était pas construit maintenant ;
s'il pourrait être remplacé temporairement par une étape manuelle ou une solution plus simple.
Classe ensuite chaque élément dans :
MAINTENANT — indispensable à la première version ;
PLUS TARD — potentiellement utile, mais pas nécessaire maintenant ;
PEUT-ÊTRE JAMAIS — aucun besoin réel fourni ne le justifie actuellement.
Ne propose pas de nouvelles fonctionnalités sauf si elles sont absolument nécessaires au résultat principal.
Si mes informations ne permettent pas de décider, indique précisément ce que je dois encore apprendre ou vérifier.
Une petite solution réduit le coût de l'apprentissage. Mais même une petite solution ou un nouvel outil peut devenir une dépense inutile si vous ne savez pas exactement pourquoi vous en avez besoin.
→ Guide suivant : Avant de payer pour un logiciel ou un service