Un brief MVP utile prend trois décisions avant le début du design : à qui s’adresse le produit, ce que la version un laissera délibérément de côté et quelles preuves utilisateurs justifieront le prochain investissement. C’est pourquoi le brief n’est pas de la paperasse. C’est la première décision produit.
Les fondateurs arrivent souvent avec un brief qui est en réalité une description de l’idée : quelques paragraphes sur le marché, une liste de fonctionnalités et une phrase sur l’avenir possible du produit. C’est suffisant pour entamer une conversation, mais pas pour livrer. Une équipe de réalisation a besoin d’un document plus court et plus précis, qui transforme l’ambition en une suite de choix testables.
Un brief utile remplit trois fonctions
1. Il identifie la personne qui a le problème
« Les petites entreprises » désigne un marché. Ce n’est pas un premier utilisateur. Un bon brief nomme la personne, le moment qu’elle traverse et la solution de contournement qu’elle utilise aujourd’hui. Un responsable de clinique qui cherche à combler les annulations de demain a un problème différent de celui d’un patient recherchant un nouveau rendez-vous, même si tous deux appartiennent au secteur de la santé. Plus le premier utilisateur est précis, plus il devient facile de décider de ce que le produit doit faire ensuite.
2. Il trace une limite autour de la version un
Une liste de fonctionnalités indique ce qui a été imaginé. Une limite de périmètre indique ce qui sera construit. Écrivez la boucle principale en une phrase, puis listez le travail qui la rend fiable : l’écran principal, l’action utile unique, les données qui la sous-tendent et le retour qui indique à l’utilisateur qu’elle a fonctionné. Tout le reste est candidat pour plus tard, et non une exigence implicite au lancement.
3. Il définit la prochaine preuve
« Lançons et voyons ce qui se passe » n’est pas un plan d’apprentissage. Décidez ce que vous espérez observer dans les premières semaines : un parcours achevé, une action répétée, une conversion payante ou un entretien mené par le fondateur avec un type précis d’utilisateur. La mesure n’a pas besoin d’être sophistiquée. Elle doit être suffisamment proche du comportement de l’utilisateur pour pouvoir modifier la prochaine décision produit.
Ce qu’il faut noter avant un écran
- Le premier utilisateur : un rôle, une situation et une solution de contournement pénible
- La boucle principale : la plus petite action qui crée de la valeur et peut se répéter
- La limite de lancement : ce qui est explicitement hors périmètre pour la version un
- L’exigence de confiance : ce que l’utilisateur doit voir, contrôler ou comprendre avant d’agir
- La prochaine preuve : le comportement ou la conversation qui mérite un nouveau cycle de réalisation
Le test de périmètre que nous utilisons
Prenez chaque fonctionnalité proposée et posez une question : rend-elle la réussite de la boucle principale plus probable pour le premier utilisateur ? Si la réponse est non, retirez-la de la première version. Si la réponse est peut-être, notez l’hypothèse qu’elle protège et trouvez une manière moins coûteuse de la tester. Cela évite qu’une fonctionnalité utile devienne une excuse permanente pour retarder le produit.
Le but d’un brief n’est pas de saisir tout ce que vous pourriez construire. Il est de rendre évidente la prochaine décision de réalisation.
— une règle que nous appliquons au lancement des produits
Questions fréquentes
Quelle devrait être la longueur d’un brief MVP ?
Assez court pour être lu d’une traite et assez précis pour arbitrer. Une à deux pages suffisent généralement lorsqu’elles identifient le premier utilisateur, la boucle principale, la limite de lancement, les exigences de confiance et la prochaine preuve.
Le brief doit-il inclure une liste complète de fonctionnalités ?
Incluez les fonctionnalités qui font fonctionner la boucle principale, puis gardez le reste dans une section d’idées ultérieures. Un espace de stationnement séparé protège les bonnes idées sans les laisser devenir discrètement des exigences de lancement.
Que faire si l’utilisateur cible reste incertain ?
Notez les deux candidats les plus solides et les preuves qui les distingueraient. L’incertitude est utile lorsqu’elle est explicite ; elle devient coûteuse lorsqu’elle se cache dans un périmètre produit trop large.
Le brief doit-il être terminé avant le début du design ?
Il doit être assez clair pour guider la première étape de design, sans être figé pour toujours. Le design peut révéler une meilleure question, mais chaque changement doit mettre à jour le périmètre et la preuve que vous cherchez à recueillir.