Keep it simple stupid

A quel point le MVP (Minimal Viable Product, produit minimal pour espérer être viable) doit-il être minimal ?

Un minimum viable product doit être aussi minimal que possible, dès lors que ça ne met pas sa viabilité en danger.

Merci Captain Obvious.

Ce week-end, je me suis retrouvé devant un problème que je ne pouvais pas résoudre simplement en hackant des trucs existants avec des bouts de ficelle pour les faire fonctionner ensemble.

J’ai commencé à réfléchir à une solution, et au bout de quelques minutes, le déclic :

Hé, mais ça pourrait être une bonne idée de business ça !

J’ai pris mon plus joli Moleskine, celui que j’utilise pour noter tous mes merveilleux projets qui ne verront jamais le jour faute de temps, d’argent, de motivation ou de compétences (faute de temps, d’argent ou de motivation pour les acquérir).

Sur la page de gauche, j’ai écrit mon problème en toutes lettres. Sur la page de droite, j’ai commencé à décrire la manière dont je pensais le résoudre.

Pendant le week-end, j’ai appliqué les conseils de Nicolas Boileau, qui n’aurait certainement pas imaginé qu’on puisse appliquer son Art Poétique à la conception d’un MVP.

Vingt fois sur le métier remettez votre ouvrage : Polissez-le sans cesse et le repolissez ; Ajoutez quelquefois, et souvent effacez

Tout à l’heure, quand j’ai rangé mon Moleskine pour une nuit porteuse de conseils, j’avais accouché d’une monstrueuse usine à gaz, aux antipodes de mon problème initial. Vue ma vitesse de développement, sortie prévue dans 10 ans.

Parle-moi de MVP.

C’est toujours pareil : le problème, la prise de conscience qu’on ne doit pas être le seul à l’avoir, l’idée de départ, et les itérations.

Ah les itérations…

J’adore les développements itératifs, parce qu’ils permettent de sortir très rapidement quelque chose, de tester, et de modifier ce qui ne va pas avant d’ajouter d’autres choses. Mais les itérations dans le brainstorming, ça devrait être interdit si on veut aboutir à quelque chose de simple.

À chaque itération, l’idée initiale se développe, on trouve de nouveaux positionnements, de nouvelles fonctionnalités, on explore de nouvelles pistes.

À chaque itération on s’éloigne du problème de départ, mais pire encore, on finit par ne plus le résoudre, alors qu’on apporte des solutions à des problèmes qu’on n’a pas encore. Juste au cas où.

Dans ce cas, la meilleure chose à faire, c’est d’arracher la page de droite du carnet, pour ne garder que la formulation initiale du problème.

Pour chaque ligne sur la page de droite, il n’y a qu’une seule question à poser :

Est-ce que ça résout mon problème initial et seulement mon problème initial ? Vraiment ?

Si c’est le cas, on garde. Si ce n’est pas le cas, on oublie. Pour l’instant.

À la fin de la journée, on doit avoir couché sur le papier les spécifications d’un produit qui apporte une réponse au besoin initial, et rien d’autre.

Il est là le MVP.

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: